Weaving Services Together & Interviews
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.
Assumes you know
After this you should be able to
- Explain the core idea in Weaving Services Together & Interviews
- Apply Weaving Services Together & Interviews in a representative design
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.
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.
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.
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. |
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.
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
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?
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.
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.
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. |
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#
🏁 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.
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.
Further reading#
All three external references resolve live. The author's own course cross-links and personal/social links from the epilogue are omitted.