Message Queue

A message queue is a piece of infrastructure that decouples the producer of a piece of work from the consumer that eventually performs it, by holding messages (units of work or data) in an ordered buffer until a worker process is ready to handle them. Instead of Service A calling Service B directly and waiting for a response (synchronous, tightly coupled, and fragile if B is slow or down), Service A publishes a message to a queue and moves on immediately; Service B (or a fleet of worker processes) consumes messages from the queue at its own pace. Why it matters for AI/SaaS builders: AI workloads are frequently slow and variable in duration — generating an image can take 5 seconds, transcribing an hour of audio can take a minute, running a batch embedding job over 10,000 documents can take much longer — and none of that belongs inside the request/response cycle of a web request, which needs to return in well under a second to feel responsive. Queues are what let a product accept a request instantly ("your video is processing"), return control to the user, and complete the actual AI work in the background, updating the user via webhook, polling, or websocket when done. How it works: a producer publishes a message (commonly JSON) to a named queue or topic; one or more consumer workers pull messages off and process them, typically acknowledging successful processing so the message is removed (or, on failure, the message becomes visible again for retry, or moves to a dead-letter queue after N failed attempts so a single poison message doesn't block the whole pipeline forever). Popular implementations range from Redis-backed job queues (BullMQ for Node, Laravel Horizon/Redis queues for PHP, Sidekiq for Ruby) for simpler workloads, to dedicated brokers like RabbitMQ, and distributed log-based systems like Kafka or AWS SQS/SNS for high-throughput or multi-consumer fan-out scenarios. Worked example: a user uploads a 45-minute podcast episode to an AI transcription SaaS. The upload endpoint saves the file, publishes a message `{job: "transcribe", file_id: "f_9921", user_id: "u_44"}` to a `transcription-jobs` queue, and immediately returns `202 Accepted` to the browser. A pool of worker processes, scaled independently from the web servers, pulls jobs off the queue, calls a speech-to-text API, writes the transcript to the database, and fires a webhook back to the frontend to update the UI in real time — meaning the web server that handled the upload was never blocked for the 3 minutes the actual transcription took.