Architecture at a glance
Microservices are typically collections of small, independently deployable services organized around business capabilities. A monolith is usually a single deployable unit where modules share a common runtime and database, which can simplify coordination. Teams might consider a modular monolith, which tries to enforce strong internal boundaries without distributed complexity. In practice, the “right” shape often reflects domain clarity and organizational maturity rather than fashion. A well-designed modular monolith can deliver many benefits people seek from microservices with far less operational overhead.
A well-designed modular monolith can deliver many benefits people seek from microservices with far less operational overhead.
Scalability, performance, and resilience
Microservices can enable independent scaling and may reduce the blast radius of failures per service. However, distributing calls across a network usually adds latency, partial failures, and consistency challenges that need careful mitigation. Monoliths can often be faster in-process and simpler to scale vertically until growth pressures appear. Real gains with microservices usually depend on production-grade observability, retries, timeouts, and circuit breakers. Microservices can scale and isolate failures per service, but the network and distributed data usually introduce new sources of latency and fragility.
Microservices can scale and isolate failures per service, but the network and distributed data usually introduce new sources of latency and fragility.
Team topology and delivery speed
Microservices often fit larger organizations where many teams need autonomy to ship and operate independently. Conway’s Law suggests architecture will tend to mirror communication lines, so decentralized teams may benefit from service boundaries. Smaller teams with an evolving domain might move faster with a well-structured monolith that avoids cross-service coordination. Data ownership and transaction design usually shift to eventual consistency and saga patterns when services multiply. If your org is small and the domain is still evolving, a clean, modular monolith tends to maximize speed of change.
If your org is small and the domain is still evolving, a clean, modular monolith tends to maximize speed of change.
Cost, risk, and migration strategy
Microservices often introduce additional costs in infrastructure, CI/CD pipelines, testing matrices, security, and governance that only pay off at certain scales. Monoliths tend to centralize complexity, which can be manageable early on but may become a bottleneck without modular discipline. A pragmatic approach is to start with a modular monolith, measure hotspots, and extract services at stable seams using a strangler pattern. Decision criteria usually include team size, domain complexity, rate of change, reliability needs, and compliance constraints. A pragmatic path is to start simple, instrument well, and then carve out services deliberately when bottlenecks or scaling needs become clear.
A pragmatic path is to start simple, instrument well, and then carve out services deliberately when bottlenecks or scaling needs become clear.
Helpful Links
Martin Fowler on Microservices: https://martinfowler.com/articles/microservices.html
NGINX — Monoliths vs Microservices: https://www.nginx.com/blog/microservices-vs-monolith/
AWS Microservices Guide: https://aws.amazon.com/microservices/
ThoughtWorks Technology Radar (architecture themes): https://www.thoughtworks.com/radar