Architecture
Microservices
Splitting a system into small, independently deployable services, each owned by a team with its own data and lifecycle. This unlocks independent scaling and deploys at organisational scale. The price is steep: network calls, distributed transactions, eventual consistency and heavy operations (discovery, tracing) — so do not start here without a concrete reason.
Purpose
Microservices split a system into small, independently deployable services, each owning its data and lifecycle. The point is organisational as much as technical: teams ship without coordinating a shared release, and each service scales and fails independently.
When to Use It
They pay off when many teams work on one product and deployment coupling has become the bottleneck, or when components genuinely need different scaling, languages or release cadences. Netflix-scale traffic is not required — team-scale friction is the honest trigger.
For a small team, they are usually premature: you inherit the costs before any of the benefits apply.
Trade-offs
Every in-process call becomes a network call that can fail, slow down or time out; transactions become sagas; consistency becomes eventual. You also buy an operations bill — service discovery, tracing, deployment pipelines per service — that a monolith never charges.
Implementation
Draw boundaries along business domains (bounded contexts), give each service its own database, and communicate via APIs or events — never shared tables. Invest early in observability (tracing, centralised logs) and resilience patterns (timeouts, retries, circuit breakers), because the network is now part of every feature.