Distributed Systems · Chapter 09 · Finale

How the pieces talk — and how to talk about them

Eight chapters built eight services. This one wires them together — how microservices communicate, find each other in a shifting network, and offload the plumbing to a service mesh — then closes the course with the part that actually gets you hired: how to handle a system-design interview, including one for a system you've never heard of.

🧭

How to read this

Two halves, mirroring the course's own ending. Part A — the plumbing: the three concerns that appear the moment you have more than one service (how they talk, how they find each other, how to stop rewriting the same networking code in every service). Part B — the meta-skill: how to actually perform in a system-design interview, including the author's strongest advice — never memorize architectures. Anything marked [+] is context I added; everything else is rewritten from the seven teaching lessons.

Part A · Inter-Microservice Communication

How services talk: sync vs. async

The platform's services (live streaming, VOD, CMS, …) run independently but constantly share data — user activity most of all. There are two ways they interact, plus a mix:

Mode	Behavior
Synchronous	Real-time. Two services interact directly; if one is down, the other waits. Tightly coupled.
Asynchronous	Not real-time. A message queue sits between the services so each processes events at its own pace; if one is down, the other doesn't wait. Loosely coupled and more efficient. Most queues use AMQP.

Example (async): the VOD service sends user data to the CMS — push to a queue, CMS pulls at its own bandwidth. Example (sync): a user buys video access → VOD sends a purchase request to the payment service; this can be synchronous because payment must happen in real time and the services are tightly coupled via the Saga pattern anyway.

⚠️

Synchronous is an anti-pattern (mostly)

Unless the use case specifically requires it, synchronous communication between microservices is discouraged and considered an anti-pattern — it hurts loose coupling and availability. The pointed question: what's the point of splitting into microservices if you then tightly couple them with synchronous calls? Default to async.

Service discovery: finding a moving target

Services run in containers/VMs, and in a distributed environment instance counts and locations change constantly — nodes are added, replaced, autoscaled, redeployed at new versions. To communicate, a service must know where another service's instances currently live. That's service discovery.

📖

The service registry

A service registry component registers every instance of every service. Enabled by it, services find each other's IP/port smoothly in a dynamic environment. Netflix's Eureka is a real-world example running at scale. The flow: VOD wants to call the payment service → asks the discovery component for its location → the registry looks it up and returns it → VOD calls the instance. (Conceptually similar to how load balancing works.)

Two ways to implement it

Approach	How it works & trade-off
Client-side discovery	The calling service fetches instance details from the registry itself and runs the load-balancing algorithm to pick an instance. Upside: one fewer network hop (it hits the instance directly, not the destination's load balancer) → better performance. Downside: the caller must implement the load-balancing logic.
Server-side discovery	The caller just hits the destination service's load balancer, which fetches instance details from the registry and routes to an instance. The caller does no discovery or load-balancing work.

Figure 1 — Client-side discovery (caller queries registry + load-balances itself) vs. server-side (a load balancer does it). Original diagram after Figures 9.4–9.5.

Registration: instances either self-register and send periodic heartbeats to avoid expiry, or are registered by an external service registrar that tracks instances and updates the registry. Those instances are tracked with the help of a service mesh — next.

Service mesh & the sidecar pattern

Microservices run in containers (Kubernetes being the de-facto orchestrator). At hundreds or thousands of instances, every service — beyond its core business logic — also has to implement auth, retries, observability, load balancing, traffic splitting, service discovery, and more. Rewriting all that in every service is madness. A service mesh with a sidecar fixes it.

🛵

Service mesh = the non-business-logic layer

A service mesh is an infrastructure layer that handles service-to-service communication and all the non-core processes (encryption, load balancing, discovery…). The analogy: a two-wheeler with a sidecar — the core business logic rides the bike (the microservice), while the plumbing rides the sidecar (a proxy running alongside every service). Developers focus on business logic; the mesh optimizes data flow. Istio is a popular example.

Control plane & data plane

Data planeThe sidecar proxies attached to each microservice. They carry all inter-service communication (services talk via the mesh, not directly) and collect telemetry on every request.

Control planeManages the proxies and traffic routing. With full traffic visibility, aggregated telemetry (e.g. average time before a retry succeeds) becomes rules — like the optimal retry wait time — cutting wasteful retries and saving bandwidth.

Figure 2 — Service mesh: sidecar proxies (data plane) carry all traffic and report telemetry to a control plane that sets routing and retry rules. Original diagram after Figures 9.6–9.8.

A proxy is an interface to something — here, to network connections — letting the mesh add logic when routing traffic. Istio uses Envoy, a high-performance C++ distributed proxy that runs alongside every service, providing consistent observability in one place. Envoy is used by Netflix, Microsoft, Google, Pinterest, Square, Stripe, and more.

Part B · Handling the Interviews

What the interviewer actually wants

System-design discussions are open-ended — there's no single right answer, only trade-offs. Companies don't expect a ninja; they expect solid fundamentals and want to gauge your thought process: do you approach an unfamiliar problem methodically, or panic?

Take ownershipThe onus is on you to explain every design choice — why this database, why a queue, why a cache. Companies want engineers they can trust to solve problems without much supervision.

Don't chase buzzwordsThey want someone who understands the use case and fits a solution to it — not someone driven by industry hype.

Start brute-forceLike a coding round, begin with a basic solution. If your mind goes blank, draw a client and a server and build up. Software is iterative — nothing is perfect first try.

Make it a conversationLead the design, bounce thoughts off the interviewer, take their input continually. Think of it as designing for your own startup.

🚫

The cardinal sin: memorizing architectures

The most common mistake candidates make is learning a system like Netflix or Facebook by heart — a strict no. These took years of engineering to perfect; you can't design Netflix-as-it-is-today in a 45-minute round, and interviewers know it. Design from the interviewer's input, not from memory.

💳

The Netflix-payments trap

Asked to design payments for a Netflix-like VOD service, a candidate who says "I'll use Cassandra because Netflix does" loses points. Netflix uses Cassandra for payments only after years of engineering — deliberately giving up relationships, ACID, and joins (flattening their data model) to hit their scale. Most started as monoliths and migrated. The right move: explain why a relational DB (strong consistency + ACID) wouldn't fit before abandoning it — most large services do use relational DBs when they need ACID. If the interviewer says up front that a relational DB can't handle the scale, that's a hint to clarify requirements, not to guess.

Designing a system you've never heard of

Nobody knows every system. Asked to design, say, a web-based MMO game you've never touched — don't freeze. The playbook: draw a client and a server, then work the requirements. Start with non-functional, then functional.

Non-functional requirements (ask first)

How many daily active users? Say 10M DAU — that alone tells you it needs a scalable, distributed design (interviewers usually want distributed to gauge your depth, even if a monolith could technically cope).
Scalability — with many concurrent players, discuss handling concurrency, horizontal scaling, and system bottlenecks.
Availability — redundancy, replication, resiliency to infrastructure failures, readiness for traffic surges.
Latency — ask about traffic regions. Global traffic → bring in edge locations, CDNs, server-side caching; low latency is key to the gaming experience. Jot everything on the whiteboard as you go.

✅

You haven't even started designing yet

Notice: just discussing non-functional requirements gives you plenty to talk about and signals real design sense — before a single box of the actual system is drawn.

Functional requirements & understanding the data

Interviewers intentionally underspecify functional requirements — they want you to ask for clarification (data types, traffic patterns, storage). Understanding the data drives your datastore choices:

If the data is…	Reach for…
Relational + needs strong consistency/ACID	A relational database.
Highly connected relationships	A graph database — or both relational + graph in a polyglot persistence model.
User state needing quick access	A document or key-value store.
BLOBs (images, videos)	Cloud object storage.

🧱

What "designing" really means here

Just by understanding the data you can already place one or more databases in the architecture. The interviewer doesn't want an overly complex solution — they want you to understand the use case, start from basics, and fit the building blocks together with the scalability/availability strategies from the whole learning track in mind. That suffices.

Recap — and the whole course in one view

CommunicationAsync (message queue, AMQP, loosely coupled) is the default; sync is an anti-pattern unless the use case demands real-time (e.g. payments via Saga).

Service discoveryA registry (e.g. Eureka) tracks shifting instances. Client-side (fewer hops, caller load-balances) vs. server-side (LB does it). Heartbeats or a registrar keep it current.

Service meshSidecar proxies (data plane) carry all traffic + telemetry; a control plane sets routing/retry rules. Istio + Envoy. Frees devs to write business logic.

Interview mindsetOpen-ended, trade-offs, own your choices, start brute-force, converse. Never memorize architectures — the Cassandra-for-payments trap.

Unknown systemsDraw client + server; work non-functional (DAU → scale, availability, latency/edge) then functional; let data type pick the datastores.

EpilogueThe course closes the Zero to Software Architect track — fundamentals over hype, discussion over memorization.

🏁 The nine-chapter journey

This page is the last of nine study pages rebuilt from Designing Modern Web-Scale Distributed Services. Together they trace a single arc: from the low-level mechanics of a single database, out to a full multi-service platform, and finally to how you'd explain all of it under interview pressure.

01 · Concurrency in Online Services 02 · Handling Database Growth 03 · Distributed Transactions 04 · Sports News & Streaming 05 · Video-on-Demand 06 · Feed + Notifications + CMS 07 · Distributed Content Search 08 · Subscription Payments 09 · Weaving It Together (this page)

💡

The single idea underneath it all

The whole course, and this finale especially, rests on one conviction: architecture is the art of matching mechanisms to requirements, not reciting famous designs. A microservice split is only worth it if you keep the services loosely coupled; discovery and a mesh exist so that decoupling survives a network that never stops changing. And the interview simply tests whether you reason that way — start from the client and the server, ask what the system actually needs, and let each requirement pull in the right building block. Understand the fundamentals deeply enough and you can design something you've never seen, which is the only skill that outlasts any specific technology.