Lesson 8Beginner1h 16mAssessment-backed

Sync vs Async Communication

Learn when services should respond immediately, when work should move to queues/events, and how retries, ordering, and idempotency affect design.

What you will be able to do

Explain synchronous and asynchronous communication in practical terms.

Choose sync or async based on user experience, correctness, latency, and failure behavior.

Understand queues, events, retries, DLQs, ordering, and idempotency at a beginner level.

Map communication patterns to AWS, GCP, and Azure services.

Use a decision checklist before adding queues or events.

Synchronous communication waits for an answer now. Asynchronous communication accepts work now and finishes it later. The decision changes latency, reliability, user experience, and operational complexity.

Sync and Async in Plain Language

If the user cannot continue without the result, the work is often synchronous. If the work can happen after acknowledgement, or must survive provider failures and retries, it is often asynchronous.

Synchronous request path compared with asynchronous queue based path — Sync optimizes immediate answers. Async protects latency and reliability for work that can happen later.

Pattern	How it feels	Use when	Risk
Synchronous API call	Caller waits	User needs immediate result	Slow dependency slows user.
Queue	Caller gets accepted response	Work can happen later and must retry	User may not see final outcome immediately.
Pub/sub event	Many consumers react independently	Multiple systems need to know something happened	Ordering and duplicate handling become important.
Stream	Continuous ordered event flow	High-volume event processing	Operational complexity and retention decisions.

Scenario: Order Confirmation

When a user places an order, some work must finish before the response. Other work should not block checkout. This separation is one of the most important production design habits.

Work	Sync or async?	Reason
Validate cart and address	Sync	User needs immediate correction.
Create order record	Sync	Order must exist before success.
Authorize payment	Usually sync or near-sync	User must know whether checkout can proceed.
Send confirmation email	Async	Can retry without blocking checkout.
Update analytics	Async	Can lag without affecting user.
Notify warehouse	Async or event-driven	Downstream systems can process after order is accepted.

Failure Behavior Decides the Pattern

The key question is not only can this be delayed. Ask what should happen when the dependency is slow or down. Async communication gives you buffering and retries, but it also introduces eventual completion and duplicate handling.

Question	If yes	Likely pattern
Does the user need the result before continuing?	Yes	Synchronous.
Can the work be safely completed later?	Yes	Queue or event.
Can the dependency be temporarily unavailable?	Yes	Async with retry and DLQ.
Do multiple systems need to react?	Yes	Pub/sub event.
Does order of events matter?	Yes	Ordered queue/stream or careful per-entity sequencing.

Design principle

Async is not a shortcut for hard work. It moves complexity from user latency into retries, idempotency, ordering, monitoring, and operational recovery.

Queues, Events, and DLQs

A queue stores work until a worker can process it. An event tells other systems that something happened. A dead-letter queue stores messages that repeatedly failed so engineers can inspect or replay them.

Concept	Beginner meaning	Example
Queue	A waiting line of work	Send confirmation email.
Event	A fact that happened	OrderCreated.
Consumer/worker	Code that processes queued work	Email worker sends message through provider.
Retry	Try failed work again	Retry provider timeout with backoff.
DLQ	Place for repeatedly failed messages	Invalid template messages go to investigation.
Idempotency	Safe repeated processing	Same OrderCreated event does not send five emails.

Cloud Communication Services

Need	AWS	GCP	Azure
Simple queue	SQS	Cloud Tasks or Pub/Sub subscription	Service Bus queue
Pub/sub fanout	SNS/EventBridge	Pub/Sub/Eventarc	Event Grid or Service Bus topic
Stream processing	Kinesis/MSK	Pub/Sub + Dataflow	Event Hubs + Stream Analytics
Workflow orchestration	Step Functions	Workflows/Cloud Composer	Logic Apps/Durable Functions
Dead-letter handling	SQS DLQ/SNS DLQ	Dead-letter topics/subscriptions	Service Bus dead-letter queue

Observability for Async Work

Async systems need different monitoring than normal APIs. A 200 response only means work was accepted, not that the background work succeeded.

Signal	Why it matters
Queue depth	Shows whether workers are falling behind.
Oldest message age	Shows user-visible delay risk.
Retry count	Reveals unstable dependencies or bad messages.
DLQ count	Shows work that needs human or automated recovery.
End-to-end completion latency	Measures time from accepted request to final outcome.
Idempotency conflict count	Shows duplicate requests or duplicate events.

Beginner Mistakes

Making everything synchronous because it is easier to reason about at first.
Making everything asynchronous and then losing clear product feedback.
Using a queue without defining retry, DLQ, idempotency, and monitoring.
Publishing events before the source-of-truth state is safely stored.
Forgetting that async work can complete out of order or more than once.

Guided Practice

Practice task

For account signup, decide which steps are sync and async: create account, send welcome email, verify captcha, create audit log, notify sales, generate recommendations.

Sample Answer

Step	Decision
Verify captcha	Sync because signup should not continue if bot protection fails.
Create account	Sync because the account must exist before success.
Create audit log	Often sync or durable event before success depending on compliance.
Send welcome email	Async because it can retry later.
Notify sales	Async because it does not affect user signup.
Generate recommendations	Async because it is expensive and can appear later.

Module 2 Wrap-Up

You now understand how clients enter systems through API contracts, how requests move through production layers, how boundaries divide responsibilities, and how sync or async communication changes reliability and latency.

Before You Continue

You should be able to choose sync vs async with a clear reason.
You should understand queues, events, retries, DLQs, and idempotency.
You should know why async work needs separate observability.
You are ready for Module 3, where service behavior meets data modeling and storage decisions.

Service Boundaries

Data Modeling for Systems