yoklainterview sim
ProgressHistory

Backend Messaging / Queues Interview Questions

75 verified Backend Messaging / Queues interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Messaging / QueuesDifficulty 1
What is the primary architectural benefit of placing a message queue between two services?
  • aEach message is processed faster than it would be with a direct HTTP call
  • bThe producer keeps working even when the consumer is slow or temporarily down✓
  • cThe consumer no longer needs error handling, because the queue retries for it
  • dThe two services can safely read and write the same database tables
Explanation:A queue decouples the producer from the consumer's availability and speed: the producer enqueues and moves on, and the backlog is processed when the consumer catches up. Per-message latency usually increases rather than decreases (a), and retries help with transient failures but do not remove the need for error handling (c).
Messaging / QueuesDifficulty 2
An endpoint lets users upload a video, and generating its preview takes about 60 seconds. Handling this synchronously causes request timeouts. What is the standard solution?
  • aRaise the HTTP timeout on the server and the load balancer to a few minutes
  • bHave the client retry the same upload repeatedly until it eventually succeeds
  • cAccept the upload, enqueue a background job, and return a response immediately✓
  • dSplit the preview generation across multiple synchronous requests
Explanation:Long-running work does not belong in the request/response cycle: accept the input, enqueue the job, and respond right away (typically with a job reference). Raising timeouts (a) keeps connections and workers tied up and only moves the limit; client retries (b) multiply the load without fixing the root cause.
Messaging / QueuesDifficulty 1
In the producer/consumer pattern, what is the producer's role?
  • aIt publishes messages to the queue without waiting for them to be processed✓
  • bIt takes messages off the queue and executes the work they describe
  • cIt monitors consumer processes and restarts any that have crashed
  • dIt stores the results of processed messages and serves them to clients
Explanation:The producer only publishes; it neither waits for nor knows about the processing, which is exactly what decouples the two sides. Option (b) describes the consumer.
Messaging / QueuesDifficulty 2
A consumer is implemented like this:
msg = queue.receive()
queue.ack(msg)
process(msg)

What is the risk of this ordering?
  • aThe broker redelivers the message because the ack arrived too early
  • bprocess(msg) runs twice for every message that is received
  • cThe consumer deadlocks while waiting for the next message
  • dIf process(msg) fails, the message is already gone and the work is lost✓
Explanation:Acking marks the message as done, so the broker removes it; a crash inside process(msg) afterwards means nothing will be redelivered — effectively at-most-once behavior. Ack after successful processing to let the broker redeliver on failure. Option (a) is backwards: an early ack prevents redelivery rather than causing it.
Messaging / QueuesDifficulty 2
A consumer takes a message from the queue and crashes before acknowledging it. What does a typical message broker do?
  • aIt deletes the message, since a delivery attempt was already made
  • bIt eventually makes the message available for delivery again✓
  • cIt pauses the whole queue until an operator confirms what happened
  • dIt immediately moves the message to the dead letter queue
Explanation:Unacknowledged messages become deliverable again after a timeout or once the consumer's failure is detected, so another consumer (or the same one after restart) gets a second chance — this redelivery is the foundation of at-least-once semantics. A DLQ (d) typically receives a message only after repeated failed attempts, not the first one.
Messaging / QueuesDifficulty 1
What does "at-least-once delivery" mean?
  • aEvery message is delivered one or more times, so duplicates are possible✓
  • bEvery message is delivered exactly one time, with duplicates ruled out
  • cSome messages may be dropped, but none are ever delivered twice
  • dEvery message is delivered at least once to each connected consumer
Explanation:At-least-once guarantees no message is silently lost, at the price of occasional duplicates (for example after a crash between processing and ack). Option (c) describes at-most-once, and (b) describes exactly-once.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview