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 8-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
You travel internationally. Your laptop has a US plug. The hotel in Germany has a European socket. You need an adapter. It doesn't change the electricity or your laptop. It transforms the interface so they're compatible.
In a architecture, you have 30 services. Some write logs in JSON. Some write plain text. Some write structured key-value pairs. Your centralized logging system (Elasticsearch) expects a specific JSON format. Your monitoring system (Prometheus) expects metrics in a specific exposition format. Your tracing system expects OpenTelemetry spans.
You could modify every service to output in the exact format each infrastructure tool expects. But that means coupling every service to your specific monitoring stack. Switch from Datadog to ? Rewrite logging in 30 services.
The Adapter container sits next to your application, reads its output in whatever native format the app produces, and transforms it into the standardized format your infrastructure expects. The app doesn't change. The infrastructure gets what it needs.
At Airbnb, their fleet includes services in Java, Ruby, and Go, each with different logging libraries and metric formats. Rather than standardize every application, they run adapter containers that normalize output to a common schema before shipping to their observability platform.
| Scenario | App Output | Adapter Transforms To |
|---|---|---|
| Log format standardization | Plain text logs | Structured JSON with timestamp, level, service name |
| Metrics format conversion | StatsD metrics | exposition format |
| Protocol adaptation | Custom binary format | REST/ |
| Data enrichment | Raw log lines | Logs enriched with pod name, namespace, node |
| Encoding conversion | JMX MBeans (binary RMI) | Prometheus text format over |
How it differs from Sidecar and Ambassador:
| Pattern | Direction | Purpose | Changes What |
|---|---|---|---|
| Sidecar | General (both directions) | Adds any cross-cutting capability | Behavior |
| Ambassador | Outbound (app to external) | Simplifies connecting to external services | Connections |
| Adapter | Outbound (app to infrastructure) | Standardizes app output for infrastructure | Format |
The Adapter is another specialization of the Sidecar pattern, focused specifically on transforming the application's output to match what downstream systems expect. The key distinction: an adapter does not change behavior or connections. It changes format.
It is easy and good
“It is really nice and good Please join the course”