Microservices architecture
Splitting a system into independently deployable services solves real problems — and creates new ones. Worth doing when the problems it solves are the ones you actually have.
Architecture
Chosen per project
Maintainable handover
Microservices are usually sold as a scalability decision. In practice they are an organisational one: they let separate teams release on their own schedule without coordinating a single deployment. If you do not have separate teams, most of the benefit is theoretical and all of the cost is real.
The cost is not small. Every call that used to be a function call becomes a network call that can fail, time out or arrive twice. Transactions that used to be one database commit become a sequence that has to be made recoverable. That is worth paying for when the independence buys you something; it is waste when it does not.
What we build with Microservices
A platform where two or more teams need to release independently
One component with a load profile completely unlike the rest of the system
Carving a specific capability out of a legacy application, gradually
Workloads that must scale to zero or burst far beyond the baseline
Where it fits — and where it does not
Good fit when
Clear domain boundaries that have already proved stable
A team that can run its own deployments and monitoring
Components with genuinely different scaling or availability needs
Consider something else when
A first version of a product — boundaries are usually wrong at the start
Small teams, where the coordination cost exceeds any release benefit
Systems dominated by transactions that span the whole domain
Do you actually need microservices?
Four questions, asked in this order. A no at any stage usually means a modular monolith is the better build.
Separate release trains?
More than one team needing to ship without waiting.
Divergent scaling?
One part of the system with a load profile unlike the rest.
Stable boundaries?
Domain lines that have not moved in months.
Operational capacity?
Somebody able to run pipelines, monitoring and on-call.
How we work with Microservices
Boundaries from the domain
Services are drawn around business capabilities that change together, not around database tables.
Start as a modular monolith
The same boundaries enforced inside one deployable, so they can be proved before they cost network calls.
Explicit contracts
Versioned APIs and message schemas, so one service can change without breaking its callers.
Failure designed in
Timeouts, retries with backoff, idempotent handlers and dead-letter queues from day one, not after the first outage.
Our typical Microservices setup
| Concern | What we use |
|---|---|
| Runtime | Containers on Kubernetes, or managed container services |
| Communication | HTTP for queries, message queues for events |
| Contracts | OpenAPI or schema-registered message formats, versioned |
| Observability | Structured logs, metrics and distributed tracing |
| Data | A database per service where ownership is genuinely separate |
Frequently asked questions
Sometimes, and rarely all at once. The usual route is to identify one capability with a clear boundary, extract it, and see what that costs before committing to the rest. If the first extraction is painful, that is useful information about the others.
As few as give you the independence you need. The number is an outcome of your team structure and scaling needs, not a target. Two well-drawn services beat twelve badly drawn ones.
No. A well-structured monolith with enforced internal module boundaries is the right answer for most business systems, and it is far easier to change while the domain is still being learned.
Topics people search for
Services built with Microservices
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
API Development
The interfaces that let your systems talk to each other, and let partners build on top of what you have.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.