The Ancestor of Microservices
Before Microservices became the dominant pattern, large enterprises used Service-Oriented Architecture (SOA). The terms are often confused in interviews and job descriptions, so it is worth understanding the distinction precisely.
Both SOA and Microservices decompose a system into services. The critical difference is in how those services communicate and how large they are.
SOA was designed primarily to integrate large, existing enterprise systems — mainframe banking applications, legacy ERP systems, and departmental databases — that were never designed to talk to each other. The integration layer was a heavyweight piece of infrastructure called an Enterprise Service Bus (ESB). The ESB was responsible for routing messages between services, transforming data formats, applying business rules, and handling security. The bus was "smart"; the services were relatively passive.
[HR System] ──┐
[ERP System] ──┤
[CRM System] ──┤──► [Enterprise Service Bus (ESB)] ──► [Web Portal]
[Mainframe] ──┘ (routing, transformation,
orchestration, security)
Microservices inverts this. The services are smart and autonomous; the communication layer is "dumb" — it just moves messages. A Kafka topic does not know what an OrderPlaced event means. The Inventory Service that consumes it does.
The practical consequence: ESBs became single points of failure and organizational bottlenecks. Every new integration required the ESB team to configure new routing rules. Microservices eliminate this bottleneck by making each service responsible for its own logic. A useful shorthand: SOA = smart pipes, dumb endpoints. Microservices = dumb pipes, smart endpoints.