🦥 How Big Apps Stay Fast

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.

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

Join 1M+ pros

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:

1. Waiter takes your order

2. Order is put in a queue

3. Chefs work on the order

4. 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 restaurant never stops running because that queue acts as a buffer between the waiter and chef.

That’s exactly what message queues do for large systems. They keep everything flowing, even when something slows down.

Key Components Of A Message Queue

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:

1. Producer creates a message and sends it to the queue.

2. Queue stores the message safely until someone’s ready to process it.

3. Consumer retrieves the message and processes it when it can.

4. (Optional) Acknowledgment/ACK: Once done, the consumer tells the queue, “I got it.”

That’s it! Simple but powerful.

Instead of breaking under heavy load, message queues let every part of your system move at its own pace without losing a single message.

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 same pattern big systems use:

• 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 usually have two parts:

• Headers (metadata): unique ID, timestamp, routing info, message type.

• Body (payload): the actual content (JSON, binary data, or text)

It’s basically a shared to-do list.

Is there specific ways to write the “message?”

Yep! Message queues have communication protocols/standards.

• AMQP (Advanced Message Queuing Protocol): used by RabbitMQ; supports exchanges, routing keys, and reliable delivery.

• STOMP (Simple Text Oriented Messaging Protocol): lightweight, text-based; often used for WebSocket-style communication.

• MQTT (Message Queuing Telemetry Transport): super lightweight; designed for IoT and low-bandwidth environments.

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?

When a consumer picks up a message but something goes wrong, the message doesn’t just disappear (thankfully).

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.

If a message keeps failing, it gets sent here instead of clogging the main queue.
You can later inspect these failed messages, fix the issue, and requeue them manually.

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)

If the consumer doesn’t send an ACK (acknowledgment), the broker assumes the message wasn’t processed successfully, or is a NACK (negative acknowledgement.)

Depending on the setup, it’ll do one of two things:

• Retry: Put the message back in the queue to try again later.

• Dead Letter Queue (DLQ): If it’s failed too many times, move it to a special queue just for failed messages.

RabbitMQ, SQS, and Kafka all support this kind of behavior.

Why Big Companies Love Them

• Asynchronous Communication: Systems can keep running without waiting on each other.

• Decoupling: Each service can be developed and scaled independently.

• Scalability

• Reliability: messages are stored, retried, and never lost.

• Workflow Management: perfect for multi-step pipelines like e-commerce, payments, or streaming data.

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:

• RabbitMQ Tutorials

• AWS SQS

• Google Cloud Pub/Sub Overview

If you want me to go more in-depth for these topics, let me know!

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.

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.