Engineering
Split the system
only where it pays
Microservices trade a hard problem you already understand for a distributed one you may not. We help you decide whether that trade is worth making, then draw boundaries that survive contact with a real organisation.
Overview
Service boundaries drawn around team ownership and failure domains, not fashion.
Begin with the honest position. Most systems that were split into services did not need to be, and the ones that did needed fewer services than they ended up with. The costs are concrete: calls that fail partially, transactions that no longer span the operation, and debugging that now requires tooling you must run yourself.
When a split is justified, the justification is usually organisational rather than technical. Six teams contending for one deployment pipeline, or a single component whose scaling profile is ten times everything around it. Those are seams genuinely worth cutting along. Layer names and lists of business nouns are not.
A fair number of our engagements reduce service count rather than increase it. Merging four chatty services that always deploy together, and that cannot be released independently in practice, removes more operational cost and more incident surface than any amount of tracing wrapped around them ever will.
- 14 to 6
- services after merging ones that always deployed together
- 27 min
- median lead time from merge to production per service
- 3 rollbacks
- across 41 traffic-shift steps, each reversed inside 4 minutes
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Boundary analysis
Event storming with your teams to find the transactions that must stay atomic, the components with genuinely different scaling profiles, and the seams matching how deployment ownership actually works.
Strangler migration from a monolith
Extraction of one capability at a time behind a routing layer, with data moved last and traffic shifted in reversible percentages, so the monolith keeps serving customers while it shrinks.
Distributed data and consistency
Saga and outbox patterns, idempotent handlers and compensating actions, with the business agreeing what eventual consistency means in each flow before it turns up in front of a customer.
Service communication
Synchronous gRPC or REST where a caller genuinely must wait, events where it must not, and explicit rules on which is permitted, so the topology does not become a call graph nobody can draw.
Platform and progressive delivery
Kubernetes with per-service pipelines, Argo Rollouts for canary and blue-green releases, and a paved-road template so a new service starts with logging, tracing, health checks and alerts already wired.
Distributed debugging
End-to-end tracing on consistent correlation identifiers, service-level objectives per capability, and dependency maps generated from live traffic rather than drawn once and left to age.
Deliverables
What you get
- Boundary analysis and recommendation, including where not to split
- Migration sequence with reversible steps and a traffic-shift plan
- Service template covering logging, tracing, health and alerting
- Saga and outbox implementations for cross-service transactions
- Service-level objectives and error budgets per capability
- Generated dependency map and per-service ownership register
Stack
What we build it with
- Go
- Java 21
- Spring Boot
- gRPC
- Apache Kafka
- Kubernetes
- Istio
- Argo CD
- Argo Rollouts
- OpenTelemetry
- Jaeger
- Terraform
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Assess the case for splitting
A two-week review of deployment contention, scaling profiles and team structure, ending in a written recommendation that sometimes says keep the monolith.
Cut the first seam
One capability with a clean data boundary is extracted first. It proves the platform, the tracing and the rollback path while the stakes are still low.
Build the paved road
A service template and pipeline so later extractions take days rather than sprints, and so every service is observable by default rather than by individual discipline.
Move data last
Traffic shifts before storage does. Once a capability is stable behind the routing layer, its tables move with dual-write and reconciliation, then the old path is deleted.
Set objectives and hand over
Each service gets a named owner, a service-level objective and an error budget. A team that cannot state its objective does not get another service.
When this is the wrong engagement
If one team deploys the whole system and no component has a distinct scaling profile, splitting it buys you distributed failure modes and a platform to operate in exchange for nothing you needed.
FAQ
Questions we get asked
- How many services should we have?
Fewer than you expect. A useful heuristic is one service per team that owns it outright, plus separate services only for components with genuinely different scaling or availability needs. If a service cannot be deployed without another, it is not a service, it is a module.
- Do we need a service mesh?
Not below roughly fifteen services. Until then, libraries and gateway configuration give you retries, timeouts and mutual TLS with far less to operate. A mesh earns its place when policy must be uniform across teams that will not adopt a shared library on the same schedule.
- What about transactions that span services?
They stop being transactions. Each flow gets a saga with explicit compensating actions, and the business decides what a partial failure should look like to a customer. That conversation is unavoidable, and having it early is the difference between a design and a support queue.
- Can you migrate us without a code freeze?
Yes. Extraction runs behind a routing layer while the monolith keeps taking traffic, so feature work continues in parallel. We ask for one constraint: no new capability is added to the part of the monolith currently being extracted, because it doubles the work in flight.
Related
More in Engineering
Engineering
Blockchain Solutions
Permissioned ledgers, tokenised assets and independently audited smart contracts.
Engineering
IoT Development
Firmware, connectivity and telemetry pipelines for devices you cannot easily reach.
Engineering
Legacy Modernisation
COBOL, Delphi, WebForms and Oracle Forms moved off, without a big-bang cutover.