RECQ Patterns
Reactive, Event-Driven Commands and Queries. Three patterns that turn "please keep it clean" into rules the runtime enforces.
RECQ · Introduction
What is RECQ?
RECQ is a small set of rules for building event-driven microservices. The Reactive Manifesto and the Reactive Principles say how a system should behave. RECQ says how it must be built so that the behaviour follows.
RECQ · Where it starts
The problem
Distributed Systems & Microservices
Spread a system across machines and you gain performance, fault tolerance and scale, and you pay in coordination. Microservices split it into small services you can deploy on their own. The catch: when any service may call any other, soon nobody can say how the whole thing behaves.
Reactive Manifesto & Reactive Principles
The Manifesto names four traits. A system should be responsive, and it stays that way under load and failure by being elastic and resilient, both made possible by being message driven. The Principles turn that into design guidance. Neither tells you how to enforce it.
RECQ · Building Blocks
Proven parts, closed assembly
None of these ideas is new. What RECQ adds is the decision to allow only these, in one closed model. Pick a pattern to see it.
RECQ · The Pattern Language
Three patterns, one architecture
Pattern 1 · Structural
RECQ System Pattern
- Components: where your application logic lives.
- Message Gateway: carries every request and response between components.
- System State Store: keeps the state of the system as an ordered log of events, the single source of truth.
“A RECQ system is a set of computational units called components that communicate by exchanging messages; state changes are published as events in the System State Store.”
Pattern 2 · Behavioural
RECQ Communication Pattern
Only three channels exist:
- Component ↔ Component: Commands and Queries, through the Message Gateway.
- Component → System State Store: publish an Event.
- System State Store → Component: consume Events.
Everything else is forbidden: no shared cache, no distributed lock, no database two components can see. Hidden links like those are what make a system impossible to read. The only shared stores are explicit in the model: the read model of a Projector and its Projection, and the state store of one consumer's replicas.
Pattern 3 · Component
RECQ Component Pattern
Exactly seven types. Each one states what it can receive, what it can send, what state it keeps and what it promises (C/c = strong/weak consistency, R/r = strong/weak responsiveness).
RECQ · The Formal Core
Why exactly seven?
Seven isn't a list someone happened to like. Describe a component by what triggers it (the outside world, a Command, a Query or an Event) and what state it keeps (none, per instance or per context). Four rules then leave exactly seven valid kinds. That makes the set minimal for this model, not a universal law.
If you know Richardson's microservice patterns, RECQ covers the same ground, as a closed set of choices instead of an open catalogue. Read the research
Build one.
Free to run in production, every feature public, client libraries under Apache-2.0.