Microservices architecture

In a microservices architecture, a single application is decomposed into multiple services that each handle one well-defined responsibility, such as authentication, billing, or notifications. Services are loosely coupled and communicate through lightweight protocols, typically REST or gRPC over HTTP, or asynchronously through a message broker.

Each service usually owns its own data store, which avoids a shared database becoming a single point of contention. Services are independently deployable, so a team can release a change to one service without coordinating a release across the entire application.

• Single responsibility: one service maps to one business capability.
• Independent deployment: services ship on their own schedule and version.
• Decentralised data: each service manages its own database and schema.
• Communication over the network: synchronous APIs or asynchronous messaging/events.
• Fault isolation: a failure in one service should not cascade to the whole system.

This independence is the core trade-off: it buys flexibility and scalability at the cost of operational and distributed-system complexity.

A monolith packages the entire application as a single deployable unit, while microservices split it into many independently deployable services. Neither is universally better; the right choice depends on team size, scaling needs, and operational maturity.

Many teams start with a monolith and extract microservices later, only when scaling pressure or organisational growth justifies the added complexity.

Microservices solve real problems for large, fast-moving organisations, but they introduce costs that smaller teams often underestimate.

Benefits:

• Independent scaling: allocate resources to the services that actually need them.
• Technology freedom: each service can use the language or database best suited to its job.
• Team autonomy: small teams own a service end to end, reducing release bottlenecks.
• Resilience: well-designed services contain failures rather than propagating them.

Drawbacks:

• Distributed complexity: network calls fail, add latency, and require retries and timeouts.
• Data consistency: transactions spanning services are harder, often requiring eventual consistency.
• Operational overhead: you need service discovery, monitoring, logging, and orchestration (commonly containers and Kubernetes).
• Testing and debugging: tracing a request across many services is harder than in a single process.

Microservices are an organisational and operational commitment as much as a technical one. They pay off when domain boundaries are clear and the team can support the tooling required.