Lesson 05 · Communication

Sync vs Async: Block or Delegate?

In a distributed system, how your services talk to each other defines the performance perceived by the user. Should you make them wait on the phone (Synchronous) or send them a text (Asynchronous) so they can go about their lives?

The Duel: Call vs Text

Synchronous (Blocking)

The Phone Call Analogy:
You call a friend for info. As long as they don't answer, you stay with your ear glued to the phone. You can't do anything else.
Impact: Time stops for the caller.

Blocking: The client waits for the response (Request/Response).
Simple to understand and debug.

Asynchronous (Non-blocking)

The Email / Messaging Analogy:
You send a message. You put down your phone and go play sports. The answer will arrive when it arrives (Fire & Forget).
Impact: You are freed immediately.

Non-blocking: The client continues their life immediately.
Ideal for long tasks (sending emails, PDF generation).

Flow Visualization

Diagram comparing Synchronous and Asynchronous flows — Top: Synchronous Flow (Client waits). Bottom: Asynchronous Flow (Client receives an immediate "ACK", work is done later).

The Magic Solution: Queues & Workers

The "Producer / Consumer" Pattern

How to do async properly? We don't let the web server do the heavy lifting. We use an intermediary.

1. Producer (API)

Receives request

"Message added!"

2. The Queue

(RabbitMQ, SQS, Kafka)

Stores pending task

3. Consumer (Worker)

Background server

Processes task when free

When to choose what?

Use SYNCHRONOUS when...	Use ASYNCHRONOUS when...
✔ The client needs the answer right away (e.g., Login, Google Search).	✔ The action is slow (> 200ms) or heavy (Video processing, Analytics).
✔ It is a simple Read (GET) operation.	✔ You want to smooth out a traffic spike (Load Leveling) to avoid crashing your DB.
✔ Transactional logic is complex (if step 2 fails, step 1 must rollback).	✔ You don't need an immediate response (Fire and Forget).

In Interviews (System Design)

The Magic Keyword: "Decoupling"

Don't just say "I use a queue". Explain why.

Problem:"If my PDF generation service goes down, the user can't order anymore."

Solution:"I decouple the order from the invoice via a Queue (SQS). If the PDF service is down, messages pile up in the queue without error for the user. Workers will catch up once the service is back."

Flash Quiz

Self-Evaluation

Your Turn

Mission: Newsletter Sending Architecture

You have to send 1 million emails. If you do a `for` loop synchronously, your server will timeout after 30 seconds.

Your mission: Draw a flow where:
1. Admin clicks "Send".
2. API responds "OK" in 10ms.
3. A Queue + Workers system handles sending in the background.

For the Curious (Bonus)

Webhooks

How do you know when an async task is finished? The server can't answer you (connection is closed).
Solution: You provide a "Callback" URL (Webhook). When the Worker is done, it calls this URL to tell you "It's ready!". It's like telling the delivery driver: "Ring my bell when you arrive".

Event-Driven Architecture

Pushing the concept to the extreme. Here, everything is an event.
"User Registered" → Queue → Worker "Welcome Email" + Worker "Analytics" + Worker "CRM".
This is the basis of modern "Reactive" and Serverless (AWS Lambda) architectures.