What is Microservices?
Microservices are an architectural pattern where a single application is built as a collection of independently deployable services, each owning its data and exposing a network API — chosen for scalability and team autonomy at the cost of operational complexity.
Microservices solve the coordination problem of large engineering organisations. Independent teams can ship independent services on independent schedules. The trade-off is the operational tax: distributed tracing, service discovery, schema versioning, eventual consistency, and a much harder local development story. For most growth-stage companies the right answer is a well-modularised monolith first, with carefully extracted services later when team count or scale demands it. We architect microservices when the cost is justified, not when it is fashionable.
What it includes
- Service boundaries aligned with business domains, not technical layers
- Each service owns its database — no shared schema
- Communication via REST, gRPC, or async events
- Centralised auth (OAuth 2 / OIDC) so services do not reinvent it
- Distributed tracing (OpenTelemetry) to debug across services
- Contract testing so services can evolve independently
How it works
Start with a modular monolith
Build the application with clear internal boundaries first. Only extract services when team boundaries, scale, or release cadence demand it.
Carve along business capabilities
Service boundaries follow business domains (Order, Catalog, Customer) — never technical layers (UI, API, DB). Conway’s Law is real; respect it.
Own your data
Every service owns its database schema. Shared databases turn microservices back into a distributed monolith — the worst of both worlds.
Pick the communication style per case
Synchronous (REST / gRPC) for query and simple commands. Asynchronous events (Kafka, RabbitMQ, SQS) for decoupling and eventual consistency.
Invest in observability before you need it
Tracing, metrics, structured logging from service one. Debugging without them at three services hurts; at thirty, it is impossible.
Frequently asked
Microservices or monolith for a new product?
Monolith. Almost always. Modular monolith if you want optionality. Premature microservices is the single biggest source of unnecessary engineering complexity in growth-stage companies.
How small is "micro"?
Size is the wrong question. Independent deployability and clear ownership are the right questions. If two services must ship together every time, they should be one service.
What about serverless functions?
Serverless functions are a deployment model, not an architecture. You can build a monolith on serverless or microservices on Kubernetes — the architectural question is independent of the runtime.