vishal patel
Applied in productionIntermediateUpdated 2026-09-23

Microservices Architecture

Structure a system as independently deployable services, each owning a business capability and its data, communicating over the network.

distributedautonomydatabase-per-servicescaling

The problem

A large monolith owned by many teams turns into a queue: every release needs coordination, one hot path forces the whole app to scale, and a single bad deploy takes everything down.

How it works

diagram

Core characteristics:

  • Organised around business capabilities, not technical layers.
  • Database per service. No other service reads your tables.
  • Independent deploys. A service can ship without coordinating with others.
  • Smart endpoints, dumb pipes. Logic lives in services, not in the bus.
  • Designed for failure with timeouts, retries, circuit breakers and idempotency.

Communication choices

StyleWhen
Sync REST/gRPCA query needs an immediate answer
Async eventsState changes other services react to (e.g. EntryPublished)
Async commands via a queueLong-running work (bulk publish, exports)
Use it when
  • Many teams need independent release cadences
  • Parts of the system have very different scale or reliability needs
  • Domain boundaries are well understood
Avoid it when
  • A small team or a new product whose boundaries are still moving
  • No investment in CI/CD, observability and platform tooling
  • Services would share one database anyway

Trade-offs

  • ✅ Team autonomy, independent scaling, fault isolation, freedom of technology.
  • ❌ Distributed-systems complexity: partial failure, eventual consistency, versioning.
  • ❌ Operational load. Every service needs a pipeline, dashboards, alerts and on-call.
  • ❌ Cross-service queries and transactions get hard. You need sagas, CQRS and API composition.
Where I've used it

Contentstack's platform runs as 60+ services on Kubernetes. The flip side showed up in developer experience: setting up a local environment meant cloning and configuring dozens of repos plus MongoDB and Redis. Our team built a Claude-driven setup agent that provisions and validates the whole local stack. Microservices shift cost onto platform tooling, and you have to pay it.

In one line

Microservices trade code complexity for operational complexity. I'd pick them for organisational scaling and uneven load, never just for "clean code", and only with CI/CD, tracing and contract testing in place.

Cheatsheet

The whole topic on one page. Click to open full screen.

Sources & further learning

Videos, courses, docs and books I recommend for this topic.

Related topics