Service architecture patterns

ORE Studio is a set of services that talk over NATS, share no tables, and act for many tenants and parties. The problems that come from this are not new. Every microservice platform meets them, and the literature names the solutions: Token Exchange, Saga, Idempotent Receiver, Bulkhead. This hub is the pattern language of the platform. It lists the established patterns ORE Studio uses, and each page states the pattern's forces, its failure handling, its pitfalls, its use here and its sources.

The purpose is a shared vocabulary. A design says "use Token Exchange" and links one page. The reader then knows the mechanism, the known failure modes and how a timeout or a retry is handled, and nobody finds them again by accident.

Three rules govern the language:

• The established name. A page is titled with the pattern's name in its source. A local name is an alias.
• A source for every pattern. A solution with no authoritative source is a local convention, and it belongs in an architecture page, not here.
• The pattern owns the mechanism; the user owns the use. A pattern page names each use and links it. The architecture page that uses a pattern links the pattern and states only its own choices. Document type: service_architecture_pattern states the contract.

The hub covers the patterns that govern how services work together across a process boundary. It does not cover code-level design patterns inside one component, user interface patterns, or the local conventions of the codegen, such as the SQL, HTTP and shell entity patterns: those have no outside source and keep their own pages. Document type: service_architecture_pattern states the boundary.

Read the groups in order. Each group answers one question about two services that must work together, and a later group often uses an earlier one.

Start from the question, not from the pattern. Find the group whose question your design faces, then read the pages in that group. Each page's * Context says when the pattern applies and * Related patterns names the alternatives. When no pattern fits, write the design without one and record the gap on the story. Do not stretch a pattern to fit.

To add a pattern, run compass add service_architecture_pattern with its group, fill in every section, cite its source, and add it to its group above. See How do I create a new doc?.

Identity and Access owns the IAM model: accounts, roles, permissions and row-level security. The identity group here owns how an identity travels between services.

Workflows owns the workflow engine. The coordination group names the patterns the engine implements; the engine's own contract stays in that cluster.

Message Queue owns the subject grammar and the message contract. The communication group names the patterns the bus carries.

NATS service patterns owns how each pattern is written on this bus: the ores.nats call, its arguments and the failure without it. The two hubs divide the work, and each states the boundary. Read a pattern here to choose the mechanism; read its NATS page to write it. A page here reaches the NATS page it specialises from its * NATS patterns section, and a NATS page names the pattern here it specialises.

• Knowledge — the index this structure note hangs from.
• Zettelkasten — what a structure note is, and why its order is authored rather than computed.
• microservices.io, A pattern language for microservices — Chris Richardson's catalogue, the model for this hub.
• Enterprise Integration Patterns — Gregor Hohpe and Bobby Woolf, the messaging patterns.
• Azure Architecture Center, Cloud design patterns — the resilience and load patterns.