RITE is the architectural model underlying Ritchie and its runtimes.
It defines the primitives, constraints, abstract machine, and phases for designing and executing distributed enterprise applications. The scope of this model covers applications running in a single datacenter or a cluster of well-connected datacenters. Multi-region semantics need to be explicitly designed by the developer. What follows is a condensed overview of that model.
Reliable. Every operation has a classifiable outcome: it succeeded, it was not attempted, or its result is unknown.
Interaction. Communication between units uses a small set of defined modes with known consistency and failure semantics.
Typed Endpoints. Every Endpoint has an explicit contract: interaction mode, schema, error types, and SLA dimensions.
2 Slice
2.1 Slice
A Slice is the unit of ownership, failure isolation, and interface. An Endpoint is a typed, network-addressable interaction target exposed by a Slice. A Slice may expose multiple Endpoints.
2.2 Locator
An Endpoint is addressed by a Locator: a stable name that survives restarts, deploys, and scaling.
2.3 Slice Kinds
An Entity Slice owns durable state. The Entity Slice defines the schema and the invariants that hold per instance. Its methods are commands and queries.
A Service Slice owns no durable state. It performs stateless computation and may invoke Entity Slices or other Service Slices. It does not own the state it reads or modifies.
A Stream Slice owns a durable, append-only sequence of Envelopes.
2.5 The Invariant Rule
A business invariant MUST NOT span across multiple Slices.
3 State
3.1 Structure
Event. An immutable record of a fact. Events are not Entities – Entities are mutable current state, Events are immutable history.
Collection. A named set of Entity instances plus indexes and materialisations associated with an Entity Slice. Collections are read surfaces.
3.3 Consistency by Form
Consistency is determined by state form and ownership. There is no runtime negotiation.
Entity instance. State modifications through Entity methods MUST be atomic. Entity instance reads are strongly consistent.
Collection. These are used for bulk queries like search, sort and aggregation. Collection reads are eventually consistent.
4 Foundations
4.1 Envelope
Every cross-Slice interaction carries an Envelope – a structured message conveying the interaction’s identity, source Slice, destination Endpoint, an ordering context where ordering matters, and an optional correlation handle for cross-Slice tracing.
4.2 Identity and Idempotency
All state-mutating cross-Slice interactions MUST be idempotent on the interaction’s identity.
4.3 Deadline and Budget
Every cross-Slice call – an Invocation, a publish into a Stream, or an Activation at a consumer – has a deadline: a cutoff by which the call must produce one of the three outcomes (§4.4). Budget is the time remaining until the deadline.
4.4 Three Outcomes
Every cross-Slice interaction produces exactly one of three outcomes:
- Succeeded – the handler ran to a verdict. The verdict is either a positive result or an application-domain rejection.
- Request not completed – the destination’s runtime knows the request did not run to a verdict. State at the destination is unchanged.
- Outcome unknown – the originator does not know whether the request ran or what its state effect was.
5 Invocation Mode
Invocation is the interaction mode in which a single Envelope is a single logical operation at the destination. The destination Slice processes the Envelope through the selected Endpoint and produces an outcome (§4.4); the originator may wait for that outcome (Sync) or not (Messaging).
Sync covers both state-mutating requests and reads. The distinction between commands and queries is a property of the operation, not a separate sub-mode.
Messaging is fire-and-deliver: the originator sends and does not wait for a processing outcome.
5.4 Entity Invocation
An Entity invocation is the unit of atomic state change for an Entity Slice.
The invocation’s writes are atomic across its participants.
5.5 Service Invocation
A Service invocation is a stateless orchestration.
6 Activation Mode
Activation is the interaction mode in which Envelopes flow continuously from a publisher into a durable Stream, and one or more consumer Slices each track their own progress through that Stream and process Envelopes individually. Each Envelope, at each consumer, is one activation – a bounded unit of processing with its own three-class outcome.
6.1 Streams
A Stream Slice is a Slice that owns a durable, append-only sequence of Envelopes from one or more publishers to one or more consumers.
A publisher is anything that emits Envelopes into a Stream. A consumer is a Slice that subscribes to a Stream and processes Envelopes from it.
7 Constraints
- C1 – Premise. Slices are independent failure domains.
- C2 – Single Ownership. Every piece of durable state has exactly one owning unit at any point in time.
- C3 – The Invariant Rule. An invariant MUST NOT span units.
- C4 – Explicit Interaction Modes. All communication between units uses one of a small set of defined modes with known consistency and coupling properties.
- C5 – Idempotent Mutations. All state-mutating operations MUST be idempotent.
- C6 – Bounded Calls. Every synchronous call MUST carry a budget: an explicit, finite time allocation.
No constraint is redundant with the others, and each addresses a distinct failure mode.