Core service
Solve cross-service consistency by design
In distributed systems, most failures hide not in the code but in how services are wired together. Consistency is not added later; it is designed in from the start.
- Duration
- 4 to 10 weeks
- Model
- Design and reference code
- Output
- Target architecture and ADRs
Signs of consistency problems
These symptoms are usually filed as separate bugs and closed one by one. The root cause is a shared gap in the design.
- When a transaction fails halfway, systems are left in different states and fixed by hand.
- Messages are lost in the queue, or processed twice.
- When one service slows down, every service in the chain slows down with it.
- Reporting queries put load on the transactional database.
- The same data lives in several services, and people argue about which copy is right.
- Tracing one event end to end means reading logs from several systems.
Choosing a pattern is an engineering decision
Event sourcing, CQRS, Saga and Outbox are not solutions in themselves; they are tools that solve a specific problem at a specific cost. Used in the wrong place, they add more complexity than they remove.
Design starts by establishing what level of consistency the system actually needs. Not every operation has to be immediately consistent, and knowing where eventual consistency is enough is what decides how far the system can scale.
Every significant decision is written down with its reasoning and the alternatives rejected. Your team does not just implement the design; it knows why it looks the way it does.
Scope
Included
- Identifying bounded contexts
- Synchronous versus asynchronous communication decisions
- Consistency model and transaction boundaries
- Saga and compensation flows
- Outbox and idempotency patterns
- Event schema and versioning
- Failure and retry policies
- Reference implementation
Not included
- Coding the entire system
- Database administration and operations
- Running performance tests
- Defining product requirements
How the design runs
- Weeks 1-2Event Storming. Business processes are mapped through events together with your team. Context boundaries emerge from this work.
- Weeks 3-4Consistency model. We decide which operation needs which level of consistency, and choose the communication style between services accordingly.
- Weeks 5-8Reference implementation. The chosen patterns are shown in working code: a Saga flow, event publishing through an Outbox and an idempotent consumer.
- Weeks 9-10Handover. The design document, decision records and reference code are reviewed with your team.
What you receive
Every part of the design becomes a concrete output your team can implement.
Who this service is not for
- Systems that run comfortably on one database and one application. A distributed architecture should come from a need, not be a goal in itself.
- Organisations that want the design only as a drawing and are not open to discussing implementation with their team.
- Projects that have already picked a pattern and only want approval.
Frequently asked questions
Do we need event sourcing?
In most systems, no. Event sourcing is valuable where a complete record of history is a business requirement; elsewhere it adds needless complexity. Our recommendation follows what the system needs.
Can we apply this design without moving to microservices?
Yes. Context boundaries and consistency rules work inside a modular monolith too, and in many cases that is the right first step.
Which technologies do you work with?
The .NET, Go and Python ecosystems; Kafka and RabbitMQ for messaging; PostgreSQL, MongoDB and Redis for data. The design is technology-neutral, and the reference implementation is written in the language your team uses.
Our current system has consistency problems. Where should we start?
In an existing system you first need to measure where the problem is. In that case we recommend starting with an Architecture Assessment.
Who owns the source code and documents?
You do. Design documents, diagrams and reference code are your property from day one.
Let’s review your design together
In thirty minutes you describe the system; we share a first view of where the consistency problems come from.