Decomposition, done honestly.
Monolith to microservices, microservices back to a modular monolith, or domain-driven decomposition that respects your team size. We will give you the answer that fits — not the fashionable one.
The problem we solve
Microservices became a default architectural choice for companies that don't have the operational maturity to run them. Conversely, some teams are stuck in monoliths that genuinely should be decomposed. We assess honestly and execute precisely — including telling you when the right answer is to consolidate, not split.
What we do
- 01Honest assessment of whether decomposition is warranted
- 02Domain-driven decomposition with bounded contexts
- 03Service extraction via strangler-fig pattern
- 04Anti-corruption layers at service boundaries
- 05Data ownership and inter-service consistency patterns
- 06Inter-service contracts (REST, gRPC, events)
- 07Service mesh where it actually solves problems
- 08Modular monolith design as a credible alternative
- 09Recomposition: microservices back to monolith where appropriate
What you receive
- Written architecture decision with trade-offs
- Phased decomposition plan with risk per phase
- Implementation of the first service extractions
- Operating model for the new architecture
Patterns we use
Ideal for
- → Companies considering a microservices move
- → Teams whose microservices proliferation has become a liability
- → Engineering leaders inheriting a system with unclear boundaries
- → Founders deciding what architectural shape the next 18 months should take
How an engagement runs
- 01
Assess
Honest review of whether decomposition is warranted. Frequently the answer is “modular monolith first, services later.”
- 02
Design
Bounded contexts, service boundaries, data ownership — written down with trade-offs.
- 03
Extract
First services extracted via strangler-fig with parallel running.
- 04
Operate
Operating model, observability and runbooks for the new architecture.
How to engage
Decomposition Assessment
Honest assessment of whether to decompose, with written decision.
Decomposition Programme
Assessment plus phased execution with our team.
Recomposition
For teams whose microservices have proliferated past usefulness — consolidation done safely.
Frequently asked.
01Won't you just recommend microservices because it's fashionable?
Frequently we recommend against. The honest answer for most teams under 50 engineers is a well-designed modular monolith. We'll tell you the truth even when it's unfashionable.
02Can you help us consolidate microservices back into a monolith?
Yes — this is some of the highest-leverage work we do. Service proliferation is real, and reversal is often the right call.
Have a problem worth solving well?
Tell us the outcome you want. We'll tell you what it takes — honestly, within a week, in writing.
Start a conversation