We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
Before became the default answer to every architecture question, there was SOA. Service-Oriented Architecture. It emerged in the early 2000s when enterprises realized that having 200 independent applications, each with its own user database, payment logic, and notification system, was unsustainable.
The problem was real. A bank had a customer database in the loans system, another in the savings system, another in the credit card system. When a customer changed their address, someone had to update it in 12 different places. When the business wanted a "360-degree customer view," nobody could build it because customer data was scattered across incompatible systems.
SOA's answer: break your enterprise into services that own specific business capabilities. A Customer Service owns customer data. A Payment Service owns payment processing. Services communicate through standardized protocols. You build new applications by composing existing services instead of rebuilding from scratch.
The idea was brilliant. The execution, with SOAP, XML, WSDLs, and the Enterprise Service Bus, got complicated. Understanding what SOA got right and what it got wrong is the foundation for understanding why microservices exist.
SOA organizes an enterprise around reusable services that expose well-defined interfaces.
| SOA Concept | What It Means | Modern Equivalent |
|---|---|---|
| Service | A self-contained business capability | |
| Service Contract | WSDL/XML schema defining the interface | OpenAPI/Protobuf spec |
| Enterprise Service Bus (ESB) | Central message routing and transformation | + Message Broker |
| Service Registry | Directory of available services and their endpoints | (Consul, Kubernetes DNS) |
| Orchestration | Central process coordinates multiple services | Workflow engine (Temporal, Step Functions) |
The key difference from a : services are independently deployable units that communicate over a network. The key difference from microservices: SOA services tend to be larger, share a database layer through the ESB, and rely heavily on centralized infrastructure.
SOA was standardized by OASIS and W3C between 2003-2007. The specifications were enormous. WSDL alone was a 100+ page spec. WS-Security, WS-Reliable Messaging, WS-Transaction, each added another layer. IBM, Oracle, and Microsoft sold millions in ESB licenses to implement these standards.
It is easy and good
“It is really nice and good Please join the course”