WSO2 Reference Architecture: Logical Patterns for Cloud-Native Systems
The Reference Architecture for Agility is a technology-neutral logical architecture based on a disaggregated cloud-based model.
At a glance
- What is it?
- WSO2 reference-architecture is a collection of technology-neutral architecture patterns and guides for designing cloud-based systems. It is most useful as an architecture reference, not as an installable application or deployment package.
- Who is it for?
- Architecture teams evaluating integration patterns should adopt this repository as a design reference after checking whether its logical guidance matches their organizational ownership, deployment and governance constraints. Platform implementers and procurement teams should not treat it as a ready-to-deploy WSO2 stack.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 39 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What WSO2 reference-architecture actually provides
WSO2 reference-architecture is a repository of architectural patterns, specifications and concept papers. Its stated purpose is to help organizations move toward an integration agile operating model using a technology-neutral logical architecture built around a disaggregated cloud-based model. That positioning makes it relevant to enterprise architects, application architects, platform architects and platform engineers who need to reason about system boundaries before selecting products.
The repository is not presented as a runnable integration suite, SDK or reference implementation. Its top-level entries are Markdown documents, images and repository configuration files. There is no documented application startup command, service endpoint or deployment manifest. This distinction matters for adoption. Teams looking for operational WSO2 components should not infer that cloning this repository will produce an API gateway, CIAM deployment or internal developer platform.
The README says the architecture can be applied in incremental stages across private, public or hybrid cloud environments. It does not supply an implementation sequence, readiness checklist or set of deployment prerequisites. The documents should therefore be used to shape decisions and review diagrams, not to certify that a particular enterprise architecture is complete.
Cell-based architecture and its ownership boundary
The Cell-based Architecture document describes functional capabilities grouped into an architecture unit based on scope and ownership. According to the README, this model is decentralized, cloud native and microservice compliant. Data can move within a cell and across cells, while governance is applied through a control plane embedded within the cells.
That description points to a cell as an operational and organizational boundary, rather than merely a deployment cluster. The repository states that capabilities are organized by scope and ownership, but the README does not document cell discovery, replication, routing, identity propagation or control-plane implementation details. It would therefore be unsafe to assume that following the document supplies a working cell framework.
The pattern may be useful when an enterprise needs explicit containment around business or ownership domains. It is less directly applicable when engineers require a centralized operating model or need a concrete topology with service discovery and failover rules. The separate document titled "Cells as the Containment Unit for Agentic Systems" indicates that cells are also being considered for agentic systems, but the README does not summarize the mechanism in that document, so it cannot establish implementation behavior.
Layered and segmented alternatives for centralized systems
The repository also documents two API-centric centralized architectures. In the segmented model, functional capabilities are subgrouped within layers based on organizational ownership, with data flowing from layer to layer. The layered model groups capabilities into layers from a System of Systems perspective, also with data moving between layers.
These are not naming variants of the cell model. The cell model is described as decentralized and places governance through a control plane embedded in cells. The layered and segmented models are centralized and organize capabilities into layers. That is a material architectural difference: a team choosing between them should decide whether decentralization and cell-contained governance fit the organization better than a centralized flow through layers.
The README describes layered and segmented approaches as reference architectures associated with API-driven transformation. It does not document a routing mechanism, synchronization protocol, consistency model or migration process. It also does not explain how data ownership is enforced when one layer depends on another. The documents can guide an initial comparison, but they do not provide enough implementation detail to implement either topology without additional decisions.
Reading the guides as a first practical use
The repository does not give installation steps, package installation commands or a first-run procedure. The practical first use is document selection. The README links the cell-based, layered and segmented architecture papers and also lists guides on trusted AI governance, platformless computing and internal developer platforms.
A team can begin by identifying the architectural question it needs to answer. Use the cell-based document for a decentralized model organized around ownership, or the layered and segmented document for centralized, API-centric structures. Use the internal developer platform paper when the concern is the platform scope beyond CI/CD and infrastructure automation. The README describes the Platformless paper as covering APIs, cloud-native middleware practices and platform engineering, but it does not provide installation instructions for that concept.
There is also a technology-specific collection, including documents on API-driven microservices, cloud-native architecture, CIAM, event-driven APIs and a digital enterprise Kubernetes-oriented WSO2 API platform. The presence of WSO2-related documents does not turn the repository into a WSO2 software distribution. The reader should check the LICENSE file and the selected document before treating any text or diagram as reusable in an implementation plan.
No code example is included here because the repository does not provide one. Inventing a deployment command would misrepresent the repository.
Technology-neutral scope and implementation limits
Technology neutrality is both the central strength and the main limitation of this repository. It lets architects evaluate logical structures without committing to a particular cloud provider, middleware product or deployment implementation. That is useful when requirements are still being debated or when an enterprise must support private, public and hybrid cloud environments.
The cost is that the repository does not resolve operational questions. The README does not specify deployment prerequisites, supported platforms, resource sizing, network topology, observability, backup, disaster recovery or upgrade procedures. It also does not define a conformance test for claiming that an implementation follows one of its architectures. These omissions make the repository unsuitable as the sole source for a production readiness review.
The repository has no GitHub releases, so there is no release-based upgrade path documented through that mechanism. Its last push was on 2026-09-14, which indicates recent repository activity at the stated fact level, but recent commits alone do not establish the stability or maintenance guarantees of the architecture guidance. The repository is not archived according to the repository metadata.
License, governance and alternatives to review first
The repository metadata identifies the license as Other, with a custom license that GitHub cannot classify. The actual permissions and restrictions must be read from the LICENSE file before copying diagrams, adapting text or incorporating the patterns into an enterprise deliverable. This article does not provide legal interpretation because the license text is not included in the repository information.
For architecture selection, the main alternative is between a decentralized cell model and the repository's centralized layered or segmented models. A cell model groups capabilities by scope and ownership, permits data movement within and across cells, and embeds governance through a control plane. A layered or segmented model centralizes capabilities and moves data from layer to layer, with segmentation tied to organizational ownership. The correct choice depends on the enterprise's desired distribution of control and authority.
Other documents provide different conceptual lenses. The Trusted AI Governance paper addresses boundaries, delegation, runtime behavior, evidence and economic exposure for agentic systems. The internal developer platform paper addresses platform scope beyond CI/CD and infrastructure automation. These are different reference topics, not interchangeable implementations. Teams should first decide whether their problem is system topology, governance of agentic behavior or internal platform scope.
Editorial conclusion
Architecture teams evaluating integration patterns should adopt this repository as a design reference after checking whether its logical guidance matches their organizational ownership, deployment and governance constraints. Platform implementers and procurement teams should not treat it as a ready-to-deploy WSO2 stack. The first verification should be the LICENSE file, followed by a review of the specific pattern against the intended cloud deployment model.
Frequently asked questions
What is WSO2 reference-architecture?
It is a repository of technology-neutral logical architecture patterns and guides based on a disaggregated cloud-based model. It is intended for organizations designing integration agile foundations for private, public or hybrid cloud environments.
Does wso2/reference-architecture provide software to install?
The repository does not document installation commands or a runnable application. Its top-level entries are Markdown documents, images and configuration files, so its primary use is architectural guidance.
Which architecture patterns does WSO2 reference-architecture compare?
The README describes Cell-based Architecture as decentralized, cloud native and microservice compliant. It also describes layered and segmented architectures as centralized models in which data moves from layer to layer.
Can I use the reference architecture in a production deployment?
The README does not provide deployment prerequisites, conformance tests, observability guidance, backup procedures or disaster recovery requirements. It should be treated as an architectural reference rather than proof of production readiness.
What license applies to the WSO2 reference-architecture repository?
The repository metadata identifies the license as Other and says that GitHub cannot classify the custom license. The LICENSE file must be reviewed directly for permissions and restrictions.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wso2-reference-architecture)Was this useful?