ORA's Architectural Layers

The previous chapters explored what ORA optimises for: observability that reveals behaviour, reflectivity that enables learning, and architecture that earns trust. This chapter turns those principles into structure by defining the layered model that organises ORA’s goals, capabilities, and technical pillars.

From Reactive to Reflective

The Reactive Manifesto¹, first published in 2014, offered a framework for designing modern distributed systems. It introduced four principles: responsiveness, resilience, elasticity, and message-driven communications.

These principles helped shape and guide an entire generation of developers and architects, myself included, to think more deeply about how systems should behave under rising user expectations and increasingly dynamic infrastructure. As the industry shifted toward cloud-native deployments, these principles became a much needed and high-level guide. This work had a significant personal impact on my own approach to architecture, and frames a lot of the thinking that went into ORA.

At that time, those principles were a needed course correction for the industry. We needed to push back against the brittleness of synchronous, monolithic I/O bound workloads that collapsed under variable load, and systems that treated failure as an edge case rather than a first-class design condition.

But nearly a decade later, the challenges we face are no longer mostly related to technical plumbing. They’re structural, cognitive, and increasingly economic, as the forces that fund large-scale software projects have shifted in significant ways over the past decade.

ORA draws inspiration from the spirit of the Reactive Manifesto, then reframes the focus for the next era of intelligent computing. ORA emphasises how systems are structured to be observable, explainable, and evolvable without major rewrites. It makes causality a first-class concern, and it raises the bar from “systems that don’t crash” to “systems we can understand, maintain, and extend, long after the original authors are gone.”

The Layered Model

ORA is built around three architectural layers.

Each layer supports the one above it. Architecture enables runtime behaviour, and runtime behaviour supports outcomes. Together, they form a structure for observable, reflective systems.

Goals (Stakeholder Outcomes)

A system should define what good looks like, and then prove it through design and implementation choices.

• Maintainable: Promotes a positive operator and customer experience
• Reflective: Causally understandable, in both real-time and hindsight
• Extensible: Responsive to business needs, evolvable without rewrites

These are the outcomes we strive for and what we expect lower layers to deliver.

Capabilities (System Traits at Runtime)

Capabilities are a reflection of design and implementation choices. If we make reasonable choices, we will enjoy a system at runtime that exhibits all of the runtime traits below.

• Resilient: Failures are isolated and recoverable
• Observable: Behaviour is transparent, not inferred
• Scalable: Load is distributed and manageable

These are the traits we expect a healthy system to demonstrate under real-world conditions, and what our architectural choices must deliver.

Pillars (Architectural Form)

These technical pillars shape the system’s internal structure and determine how change, flow, and understanding are supported. They enable the outcomes and capabilities of the layers above.

• Event-Sourced: State is recorded as a sequence of durable events to be preserved indefinitely. Current state can always be derived from the event journal.
• Message-Driven: All intent is expressed through commands and results in emitted events. Side effects are described, never executed inline, and effect execution is properly encapsulated.
• Read-Write Decoupled: Query models and command models follow separate paths, scale independently, and evolve without entanglement.

The next chapter examines each of these three pillars in technical depth, covering the formal models, consistency boundaries, and design tradeoffs that make them work in practice.