Sponsored by
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a great week.
Quick question!
These last few newsletters have been a little bit more in-depth with info and longer than usual, so I wanted your thoughts on it.
Do you like the more in-depth advice?
The Gold standard for AI news
AI keeps coming up at work, but you still don't get it?
That's exactly why 1M+ professionals working at Google, Meta, and OpenAI read Superhuman AI daily.
Here's what you get:
Daily AI news that matters for your career - Filtered from 1000s of sources so you know what affects your industry.
Step-by-step tutorials you can use immediately - Real prompts and workflows that solve actual business problems.
New AI tools tested and reviewed - We try everything to deliver tools that drive real results.
All in just 3 minutes a day
Message Queues
When I first heard about message queues, I thought they were one of those “enterprise things” that only engineers at Google or Amazon cared about.
And honestly? I wasn’t wrong.
You rarely need a message queue for a hobby project or a small side app.
When you’re the only user, you don’t exactly need a system built to handle millions of requests per second.
So why should I even care then?
Fair question.
Even if you’re not building at that level yet, understanding how message queues work prepares you for the moment you are.
At some point in your career, you’ll either build something that grows faster than expected, or you’ll join a team managing systems that already handle massive scale.
And when that happens, you’ll know how to keep things running smoothly.
So let’s break down what message queues actually do, how they work, and why they keep big systems from melting down.
What is a Message Queue?
A message queue is a system that allows different parts of an application to communicate asynchronously.
Instead of one service waiting for another to finish, a queue acts as a buffer in between.
It holds messages until another part of the system is ready to process them.
Think of it like a restaurant:
Waiter takes your order
Order is put in a queue
Chefs work on the order
Waiters pick them up when ready.
If something happens to the chefs and there’s a delay or even failure, new orders can still come in.
The queue gives the system breathing room: producers can keep accepting work for a while even if consumers slow down. But queues have limits too—if consumers stay unhealthy or backlog grows without bound, eventually you still have a problem.
That’s what queues are great at: smoothing bursts, decoupling producers from consumers, and giving work somewhere durable-ish to wait when the broker and queue are configured for durability.
Key Components Of A Message Queue
Component | Role |
|---|---|
Producer / Publisher | Creates and sends messages or events. |
Queue / Topic / Log | Stores or retains messages according to the system’s model. |
Consumer / Subscriber | Reads and processes messages. |
Broker / Messaging System | Accepts, stores, routes, or exposes messages to consumers. RabbitMQ, SQS, Kafka, and Pub/Sub all do this differently. |
Acknowledgement / Offset / Visibility State | Tracks processing progress. The exact mechanism depends on the system. |
Message / Event | The payload plus whatever metadata the messaging system carries. |
A single queue can have multiple producers and multiple consumers, all working independently.
How Message Queues Work
Here’s the basic flow of a message queue:
A producer publishes a message or event.
The messaging system stores, routes, or retains it according to its configuration.
A consumer reads the message and attempts the work.
The system records progress somehow—for example an ACK, deleting the message after success, changing visibility, or committing a consumer offset.
That’s it! Simple but powerful.
Queues can absorb bursts and help isolate slow consumers, but they do not guarantee that every message is processed exactly once. Real systems choose trade-offs between durability, latency, throughput, duplicates, ordering, and failure recovery.
A Tiny Example
Here’s a minimal Python example using the built-in queue module. No broker, just showing the flow:
import queue
import threading
import time
# Create a queue
q = queue.Queue()
# Producer
def producer():
for i in range(5):
message = f"Task {i}"
print(f"🦥 Producing: {message}")
q.put(message)
time.sleep(0.5)
# Consumer
def consumer():
while True:
message = q.get()
print(f"⚙️ Consuming: {message}")
time.sleep(1)
q.task_done()
# Start threads
threading.Thread(target=producer).start()
threading.Thread(target=consumer, daemon=True).start()
q.join()
print("✅ All messages processed!")This little demo shows the producer → buffer → consumer pattern, but it is not a distributed message broker. Python’s in-process queue.Queue disappears if the process dies and does not provide network durability, replication, retries, or cross-machine consumers.
The producer sends,
The queue holds,
And the consumer processes asynchronously.
If you’re curious how it works with a message broker, rabbitmq has a great hello world section!
What exactly is the “message?”
Messages often contain a payload plus metadata, but the exact structure depends on the messaging system and application.
Metadata: message ID, timestamp, routing key, headers, schema/version, trace ID, partition key, etc.
Payload: JSON, binary data, text, Avro/Protobuf, or another serialized format.
For a work queue, it can feel like a shared to-do list. For an event stream such as Kafka, the better mental model is an append-only log that consumers read independently.
Is there specific ways to write the “message?”
Different messaging systems expose different protocols and delivery models. Some examples:
AMQP — commonly associated with brokers such as RabbitMQ; includes concepts like exchanges, bindings, routing keys, queues, and acknowledgements.
STOMP — a simple text-oriented messaging protocol supported by several brokers; it can also be carried over WebSockets.
MQTT — a lightweight publish/subscribe protocol popular in IoT and constrained networks.
Kafka’s protocol — built around partitioned append-only logs, offsets, consumer groups, and retention rather than traditional “message disappears after ACK” queue semantics.
You don’t have to memorize them, but it’s good to know how messages are structured, delivered, and acknowledged between systems.
What happens if the message fails?
What happens after a consumer fails depends entirely on the messaging system and configuration. A message might become visible again, be redelivered, remain in a retained log, move to a dead-letter destination, or be lost if durability was not configured correctly.
Here’s what usually happens depending on how your queue and broker are configured:
⚰️ 1. Dead Letter Queues (DLQs)
A DLQ is basically a graveyard for problematic messages.
With systems that support dead-lettering, repeatedly failing messages can be routed to a dead-letter queue/topic after some retry policy or receive-count threshold. You can inspect them, fix the underlying issue, and decide whether to replay them.
Example uses:
Log bad messages for debugging.
Alert the dev team when the DLQ starts filling up.
Trigger automated retries or cleanup scripts.
2. No Acknowledgment (NACK)
Acknowledgement behavior is system-specific. RabbitMQ consumers can ACK/NACK messages. SQS uses a visibility timeout and deletes messages after successful processing. Kafka consumers track offsets rather than ACKing each record in the same way.
Depending on the system, a failed processing attempt can lead to:
Redelivery / retry — the same work may be attempted again.
Dead-lettering — move a poison message aside after repeated failures.
Manual recovery — an operator inspects and replays failed work.
Retention for replay — stream systems can keep events for hours, days, or longer so consumers can reread them.
This is also why consumers should usually be idempotent: many production systems provide at-least-once delivery, so the same message can legitimately be processed more than once after retries, crashes, or network failures.
Why Big Companies Love Them
Asynchronous communication: producers can hand off work instead of waiting for every downstream step.
Decoupling: producers and consumers can evolve and scale more independently.
Backpressure / buffering: short traffic bursts do not have to overwhelm consumers immediately.
Durability and recovery: durable messaging systems can retain work across failures—but only with the right replication, persistence, retention, and acknowledgement settings.
Workflow and event processing: useful for background jobs, payments, emails, media processing, analytics, and event-driven systems.
You might not need a message queue today, but understanding them changes how you think about building systems.
They’re not just for “big companies”, they’re what make big companies possible.
Interested in learning more?
Check out these useful resources:
If you want me to go more in-depth for these topics, let me know!
If you want to keep learning
5 system design resources — go deeper on scalability, databases, distributed systems, and architecture.
Rate limiting explained — another way large systems protect themselves under heavy traffic.
Microservices explained — how splitting systems into services changes communication, scaling, and failure modes.
Thanks to everyone who submitted!
TokugawaBonaparte, OneDollarCat, ipaixaol, grcc492, Siddhesh-Ballal, gcavelier, Yeshua235, Mansi090, Vimalmr, AspenTheRoyal, NeoScripter, s4ngyeonpark, Suji-droid, and alfalconetti!
Phone Number Letter Combinations
Given a string of digits (from '2' to '9'), return all possible letter combinations that the digits could represent, using the mapping on a telephone keypad:
If the input is an empty string, return an empty list.
You may return the results in any order.
Examples
def letterCombinations("23")
output = ["ad","ae","af","bd","be","bf","cd","ce","cf"]
def letterCombinations("")
output = []
def letterCombinations("2")
output = ["a","b","c"]
def letterCombinations("27")
output = ["ap","aq","ar","as","bp","bq","br","bs","cp","cq","cr","cs"]
def letterCombinations("234")
output = [
"adg","adh","adi","aeg","aeh","aei","afg","afh","afi",
"bdg","bdh","bdi","beg","beh","bei","bfg","bfh","bfi",
"cdg","cdh","cdi","ceg","ceh","cei","cfg","cfh","cfi"
]
def letterCombinations("79")
output = [ "pw","px","py","pz","qw","qx","qy","qz", "rw","rx","ry","rz", "sw","sx","sy","sz"]How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
