Skip to content

Engineering

Microservices

An architecture that splits an application into small, independently deployable services instead of one large codebase.

A microservices architecture breaks a system into small services that each own one capability and can be built, deployed and scaled independently. The appeal is organisational as much as technical: separate teams can own separate services and move without waiting on each other.

The cost is that you have traded the complexity of a large codebase for the complexity of a distributed system, network calls that can fail, data spread across services, and the operational burden of running many things instead of one. Microservices are a good answer to real problems of scale and team size, and a common source of self-inflicted pain when adopted before those problems exist. A well-structured single application ("monolith") is often the right starting point.

Working out whether you need Microservices?

Definitions are the easy part. If you are trying to decide whether Microservices belongs in your system, describe what you are building and a senior engineer will give you a straight answer, including when the answer is that you do not need it.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.

Two fields required. We reply to real enquiries. No list, no sequence.