Async & Message Queues

Preview — 3 of 10 questions

A user uploads a video on your platform. The server must transcode it to 4 formats (1080p, 720p, 480p, 360p), which takes 90 seconds. Which architecture is correct?

javascript

Async flow:
  Client ──POST /upload──▶ API
  API saves file to S3
  API enqueues { jobId, fileKey } to queue
  API ──202 Accepted, { jobId }──▶ Client

  Worker pool:
  Worker picks job from queue
  Worker transcodes (90 seconds)
  Worker updates job status to "done"

  Client polls GET /jobs/{jobId} or receives WebSocket notification

AAccept the upload immediately, enqueue a transcoding job, return 202 Accepted, and process asynchronously in background workers.

BTranscode synchronously in the HTTP request handler — the client waits 90 seconds for the response.

CReject the upload and ask the user to retry during off-peak hours.

DRun transcoding on the client device to avoid server load.

Service A needs to trigger work in Service B. Why might a message queue be better than a direct HTTP call from A to B?

javascript

Direct HTTP call (tight coupling):
  A ──POST /process──▶ B (down!)
  A receives 503 → work is lost or A must retry with backoff
  Retry adds complexity to A: exponential backoff, idempotency, circuit breaker

Message queue (loose coupling):
  A ──publish──▶ Queue (persisted)
  B (down) ......... Queue holds message
  B recovers ──▶ Queue delivers message ──▶ B processes successfully
  A never knows B was down — it only talks to the queue

AMessage queues are always faster than HTTP because they use UDP instead of TCP.

BMessage queues automatically encrypt payloads; HTTP calls do not.

CHTTP calls cannot carry more than 1 KB of data; message queues have no size limit.

DIf Service B is temporarily down, the message stays in the queue and is processed when B recovers. With direct HTTP, the request fails and the work is lost unless A implements retry logic.

What is the key architectural difference between pub/sub messaging and point-to-point messaging?

javascript

Point-to-point (Queue):
  Producer ──message──▶ [ Queue ] ──▶ One consumer
  Consumer A or Consumer B picks it up (load balanced)
  Use case: job distribution, task queues

Pub/Sub (Topic):
  Publisher ──event──▶ [ Topic ]
                         ├──▶ Subscriber 1 (email service)
                         ├──▶ Subscriber 2 (analytics service)
                         └──▶ Subscriber 3 (notifications service)
  ALL subscribers receive their own copy
  Use case: event broadcasting, system integration

APub/sub uses TCP; point-to-point uses UDP.

BIn pub/sub a message is broadcast to all subscribers of a topic; in point-to-point a message goes to exactly one consumer from a queue.

CPoint-to-point supports multiple publishers; pub/sub supports only one.

DPub/sub guarantees exactly-once delivery; point-to-point only guarantees at-most-once.

Answer all 10 questions (7 more), see explanations for every answer, and track your score.