Monoliths, SOA and microservices

Three ways to structure an application

A monolith packages all features, such as login, catalogue, orders and payments, into one program that is built, tested and deployed together. It usually shares one database. Many successful systems start this way because it is simple to develop and run.

Service-oriented architecture (SOA) became popular in the 2000s. Large enterprise functions, such as "customer" or "billing", are exposed as reusable services, often using SOAP and XML. An enterprise service bus (ESB) sits in the middle, routing and transforming messages between them. SOA improved reuse across departments, but the central bus could become a bottleneck and a single team's responsibility.

Microservices split an application into small services, each focused on one business capability, owned by one team, deployed independently and owning its own data. They talk through lightweight APIs (often REST or gRPC) or events, and run on containers and orchestrators such as Kubernetes. Logic lives in the services ("smart endpoints, dumb pipes"), not in a central bus.

Comparing the trade-offs

Network and security implications

Moving from a monolith to microservices turns internal function calls into network traffic. That changes the engineer's job:

• More east-west traffic: services talk to each other inside the data centre or cluster, so internal segmentation and policies matter as much as the perimeter.
• Service-to-service authentication: each call should be authenticated, often with mutual TLS (mTLS) issued by a service mesh, plus authorisation per API.
• API gateway: a single entry point for external clients that handles authentication, rate limiting and routing.
• Observability: you need central logs, metrics and distributed tracing to follow one request across many services.
• Larger attack surface: more APIs, images and dependencies to scan and patch.

Choosing and migrating

Microservices are not automatically better. For a small team or a new product, a modular monolith, a single deployable app with clean internal boundaries, is often the best start. Move to microservices when you have clear reasons, such as parts that need very different scaling, teams blocked by a shared release, or very different technology needs.

To migrate, many teams use the strangler fig pattern: put a routing layer in front of the monolith and move one capability at a time into a new service, until the old code can be retired.

Tip: a "distributed monolith" is the worst of both worlds: many services that must still be deployed together because they share a database or call each other synchronously in long chains. Watch for this warning sign.