DEV Community: Meeth Gangwar

🔑 Unlock Rust's Power: Demystifying Ownership.

Meeth Gangwar — Thu, 27 Nov 2025 17:19:13 +0000

Everyone tells you Ownership is Rust's biggest hurdle, but what if it's actually the key to writing blazing-fast, memory-safe code? Many developers struggle, but they don't have this guide. I'm cutting through the complexity with two rock-solid, practical examples that will shift your perspective, ensuring you never second-guess the compiler again. Ready to solve the mystery? ✨

🧠 Stack vs. Heap: Where Rust Stores Your Data.

Before we face the "Borrow Checker" dragon, we need to master the two foundational memory concepts Rust uses to organize variables: the Stack and the Heap. The Stack is lightning-fast ⚡, operating strictly by LIFO (Last-In, First-Out). Since data is retrieved simply by "popping" it off, the compiler loves it! However, the Heap requires more effort. Data is stored at a dynamically assigned memory address, meaning the compiler must first chase the pointer to the address, making it slower than the Stack. The simple rule: fixed-size types

(like i32, bool)

live on the Stack, while variable-size types

(like String, Vec<T>)

are stored on the Heap.

🧐 Understanding Metadata and Pointers in Rust

Whenever you work with variable-size data stored on the Heap, Rust always maintains the essential metadata for that data on the Stack. This is a crucial distinction!

Let's look at this simple example to see the memory allocation in action:

fn main(){
let x:i32 = 5;
let y:String = String::from("Hello");
}

When this function runs, the execution context (fn main) and both variables (x and y) are allocated on the Stack.

When it comes to x, since it is a fixed-size type (i32), the value 5 is stored directly on the Stack within x itself. Easy!

However, the story is different for y (String), which is a variable-size type. y holds the metadata of the string inside the Stack, not the actual data ("Hello").

This metadata is the secret sauce! It consists of three key pieces of information:

A Pointer ptr: The memory address pointing directly to where the actual "Hello" data is located on the
Heap.Length len: The number of bytes the data currently uses (e.g., 5 bytes for "Hello").
Capacity : The total amount of memory currently allocated on the Heap for future growth.

This setup creates a crucial link! The image below clearly illustrates what x and y look like inside the Stack, showing how y's pointer leads the way to the Heap data. 👇

🤝 Understanding Copy vs. Move: The Final Piece

Understanding the copy and move is the final thing which will help you understand ownership.

Mastering Copy and Move semantics is the final step to truly understanding Ownership. For data types that are fixed-size and stored on the Stack (like i32), the operation is simple and cheap , the data is just copied.

fn main(){
let x:i32 = 5;
let y:i32 = x;

println!("{} {}",x,y);
}

This works perfectly! The value of x is cheaply duplicated into y, and both variables remain fully usable. ✅

However, the story flips completely for variable-sized values stored on the Heap. Let's try the same duplication pattern with a String in rust playground:

As you can see, the compiler throws a panic-inducing error! 🤯 This is because when x is a variable-sized type, the statement let y = x; triggers a Move instead of a Copy. To prevent catastrophic memory errors (like trying to free the same memory twice—a "double free"), Rust implements a brilliant, strict rule: the metadata (Pointer, Length, Capacity) of x is moved entirely to y. Crucially, the ownership of the Heap data is passed to y, and x is immediately dropped, making it unusable! 💔

Hence, y is the only variable left on the Stack with the valid metadata pointer, guaranteeing only one owner is responsible for cleaning up the Heap memory. This is the heart of Rust's safety. 🔒

Finally Mastering Ownership with Solid Examples!:

At its core, Ownership in Rust is technically the passing of metadata (the Pointer, Length, and Capacity) stored on the Stack from one variable to another. This rigid rule is critical for memory safety, preventing dreaded memory leaks and data races by ensuring there can only ever be one owner for variable-sized data at any given time.

The scope matters! A variable's ownership is only valid within the block ({...}) where it is defined. Once execution leaves that scope, the owner variable is dropped, and its data is cleaned up. 👋

Eg 1: Passing into a Function (The Classic Move)

fn main() {
    let s = String::from("hello"); // 🌟 s is the owner here
    takes_ownership(s);           // 💥 OWNERSHIP MOVED! s is now invalid!

    let x = 5;
    makes_copy(x);               // ✅ Copy: x is fine (fixed size)
}

fn takes_ownership(some_string: String) {
    println!("{}", some_string); // 👑 some_string is now the owner
}

In this example, when s is passed to takes_ownership(), the metadata pointer is MOVED to the function parameter some_string. Because Rust enforces a single owner, the variable s is instantly dropped (invalidated) right after the function call. You couldn't use s again if you tried! However, x is an i32 (fixed-size), so it is copied, and x remains perfectly usable.

Example 2: The Give-and-Take of Ownership 🎁

fn main(){
let s1 = give_ownership();
let s2 = String::from("hello")
let s3= takes_and_give_back(s2)
}

fn gives_ownership(a_string:String)->String {
let some_string = String::from("hello1")
some_string
}

fn takes_and_give_back(a_string:String)-> String {
a_string
}

🧠 Challenge: Before looking at the solution, identify which variables are dropped and where the final owners live!

Solution:
1.let s1 = give_ownership();

Inside gives_ownership, some_string is created ("hello1").
When the function returns some_string, the ownership of the "hello1" data is MOVED out of the function scope and assigned to s1.
Result: s1 is the proud owner of "hello1".

let s2 = String::from("hello")

s2 starts as the owner of the "hello" string.

let s3 = takes_and_give_back(s2)

When s2 is passed to takes_and_give_back, $\mathbf{s2}$ is dropped! 😭
The function parameter takes ownership of "hello".
The function immediately returns the same string back out.
This return operation MOVES ownership out of the function.
Result: The ownership of the "hello" string is MOVED from the function's return value and assigned to s3. S3 now holds the final pointer!

The takeaway: Ownership is always moved on assignment or function call for Heap-allocated types, and the only way to get it back is to explicitly return it! 🔄

🚀 The Advantage and The Final Verdict!

I truly hope those two core examples locked in your understanding of ownership! Now you see that Rust's approach isn't a hurdle—it's a superpower! 💪

This system delivers two enormous, non-negotiable advantages:

- Goodbye, Dangling Pointers! 🚫 Because ownership is always clear and exclusive (there can't be two active owners), Rust prevents the infamous "dangling pointer" problem and data races. You can forget about multiple variables trying to change the same value in parallel and corrupting your data!
- Zero Memory Leaks (The Cleaner Code Guarantee)! ✨ Since ownership determines exactly when a value is dropped, Rust ensures every piece of memory allocated is properly cleaned up. No more strong reference cycles causing memory leaks—that entire class of bugs is effectively eliminated.

Thank you so much for sticking with this deep dive! You've officially conquered the most feared topic in Rust. Go forth and write safe, blazing-fast code! I'll be back soon with more insightful articles. Until then, happy coding! 👋

*Regards, *
Meeth

Consistent Hashing: The Unseen Engine

Meeth Gangwar — Fri, 07 Nov 2025 14:34:24 +0000

🚀 Consistent Hashing: The Secret Behind Tech Giants! 🚀

Consistent hashing is one of the most powerful techniques in system design, and it's the hidden engine behind many major platforms you use every day, including:

1️⃣ Amazon DynamoDB
2️⃣ Discord
3️⃣ Apache Cassandra
4️⃣ Akamai CDN
5️⃣ Google's Maglev Load Balancer

This isn't just an academic concept—it's a fundamental system that powers modern, scalable applications. 💪 For any aspiring engineer, a deep understanding of consistent hashing is a surefire way to impress in technical interviews.

Ready to unlock the magic? Let's take a deep dive right now! 🎯

🔑 What is Hashing?

Before we dive into the magic of Consistent Hashing, we need to start with the fundamental question: What is hashing?

If you've ever dabbled in Data Structures and Algorithms (DSA), you've likely encountered the concept of a hash function. At its core, hashing is a process that takes an input (or "key") and uses a hash function to map it to a fixed-size value, typically a number or a hash code.

This powerful technique allows us to generate unique (or nearly unique) hash values. These values are incredibly versatile—they can act as a unique index in a hash table for lightning-fast data retrieval 🚀, or, as we're about to see, identify a specific node in a distributed system using consistent hashing!

Think of it as the ultimate organizer, turning complex data into a simple, manageable address.

🎯 Understanding the Problem: Why We Need Consistent Hashing

Imagine you have n cache servers, and you need to balance incoming requests across them. A simple approach is to assign each request to a server using a serverIndex.

We can generate this server index using a hash function:

serverIndex=hash%n

Example: With 4 servers (n=4):
Request "user_123" → hash = 15 → 15 % 4 = 3 → Server 3 🎯
Request "order_456" → hash = 22 → 22 % 4 = 2 → Server 2 🎯

💥 The Problem: Scale Changes Break Everything!
This works perfectly... until the number of servers changes!
What happens when:

➕ A server is added? (n=4 → n=5)
➖ A server goes down? (n=4 → n=3)

Suddenly, our formula changes:

serverIndex = hash(request_key) % 3 # Now with 3 servers

The result? 📊 Massive cache misses! Most keys now map to different servers, requiring expensive data reshuffling and causing system-wide disruption.

🔑 The Core Issue
The fundamental problem is that changing 'n' affects nearly ALL mappings, breaking the connection between keys and their servers.

This is exactly why we need Consistent Hashing! 🚀 It provides a smart way to handle scale changes while minimizing disruptions.

🎪 Let's Build the MAGIC HASH RING! 🎪:

Ready for some hashing circus tricks? 🤹♂️ In consistent hashing, we work with two main characters: the Hash Ring and the Hash Slot!

🔮 Meet Our Magic Wand: The SHA-1 Hash Function!
Instead of regular hash functions, we use the mighty SHA-1! This isn't your average calculator—it creates a MASSIVE hash space from:
0 to 2¹⁶⁰ - 1

🎯 Understanding the Hash Space:
X₀ = The starting point (our humble 0)
Xₙ = The grand finale (2¹⁶⁰ - 1)

🔄 The Great Ring Illusion!
Here's where the magic happens! By connecting our starting point X₀ with our ending point Xₙ... POOF! ✨ We create a HASH RING!

Wait, but how? 🤔 Imagine taking a straight line and bending it until the ends meet! That's exactly what we do here:
🎠 Physical Reality: It's actually a straight line (like unrolling a ring)
🎡 Mathematical Magic: We treat it as a continuous circle!

Think of it like a cosmic hula hoop where our hash values can dance around forever! 💫 The moment a value reaches the end (Xₙ), it seamlessly continues from the beginning (X₀)!

So remember: While it's physically linear, in our digital wonderland, it's the most magnificent ring you'll ever encounter! 🎉

🎯 How Do We Use This Hash Ring? Let's Play Matchmaker! 💍:

🎪 Step 1: Mapping Our Players onto the Ring!

Using our trusty SHA-1 hash function, we place everyone on the ring:

🎭 Servers: We map each server using its name or IP address
🎯 Keys: We map each incoming client request (the keys)

Both servers and keys now live together in our massive SHA-1 universe (that 0 to 2¹⁶⁰ -1 space we talked about)! The hash function acts as the ultimate bouncer, deciding exactly where each player gets to stand on our cosmic ring. 🪐

🔍 Step 2: The Treasure Hunt Rule! 🗺️
Here's the golden rule for key-server matching:

"Look clockwise and claim the first server you find!" 🔁

When a key arrives, it spins around the ring clockwise ⏩ and the first server it encounters becomes its designated home! That's the server it will talk to for all its data needs.

The image above shows exactly how our key goes on its clockwise treasure hunt! 🏴‍☠️

🎪 Step 3: Handling Changes - The Dynamic Dance! 💃
What happens when a new server joins the party? 🆕
We simply add it to the ring!
Keys get redistributed automatically - some will now find this new server first in their clockwise journey!

Result: Smooth scaling with minimal disruption! 🎉

What if a server leaves? 👋
No panic! The key simply continues its clockwise search and finds the next available server.
Result: The show goes on! The system self-heals like magic! ✨

💡 But the question arises:

If the server which was just removed was the only one which had the value for the keys accessing it, when it's gone the keys accessing the new server (found in the clockwise direction) will not find their data there. So how is this being handled?

🛡️ This is handled with REPLICATION!
In real-world systems, data is never stored on just one server. Instead, consistent hashing is combined with replication strategies where each piece of data is stored on:

The primary server (first server found clockwise)

Plus the next N servers in the clockwise direction (replica nodes)

🎯 Example:
If we have replication factor N=2:
Data for key "X" is stored on Server A (primary)
AND also replicated on Server B and Server C (the next 2 servers clockwise)
When Server A fails:
Key "X" now finds Server B as its new primary
But Server B already has the data because it was a replica! 🎉
No data loss occurs!

This way, even when servers come and go, your data remains safe and accessible through the replicated copies! 🔄

But wait there still seems to be a problem. There can be a case where there are too many keys between two server while less keys between two different server. The distribution of the key is not well managed!! This is where virtual node comes into picture.

🎪 Virtual Nodes: The Ultimate Load Balancers!

You've spotted the critical flaw in basic consistent hashing! 🚨

💥 The Problem: Uneven Distribution "Hotspots"
Even with our fancy hash ring, we can end up with:
🔥 Hotspots: Some servers drowning in keys while others sit idle
📊 Uneven Load: Random distribution can create massive imbalances
😭 Inefficient Scaling: New servers might not relieve the overloaded ones

🎯 How Virtual Nodes Save the Day!
Virtual nodes create multiple "virtual" positions for each physical server on the hash ring:

Physical Server A → Virtual Nodes: A₁, A₂, A₃, A₄ Physical Server B → Virtual Nodes: B₁, B₂, B₃, B₄ Physical Server C → Virtual Nodes: C₁, C₂, C₃, C₄

✨ The Magic Results:
🎲 Better Distribution: More positions = more chances for even spread
⚖️ Load Balancing: Heavy key ranges get distributed across multiple virtual nodes
🔄 Smooth Scaling: Adding/removing servers affects smaller chunks of data
🎪 No More Hotspots: Keys get distributed across all virtual nodes evenly!

🏗️ Real-World Example:
Cassandra uses virtual nodes by default - each physical node has 256 virtual nodes, creating that beautiful even distribution we dream of! 💫

Conclusion:

And that is it this is all there is to when it comes to consistent hashing. This is one of the most important concepts when it comes to system design and I think every senior software developer should have a idea about it.

That said I will keep coming up with more intresting concepts in the future until then signing off!!

Regards,
Meeth

"The Architecture Behind Uber Live Tracking" ⚡

Meeth Gangwar — Fri, 17 Oct 2025 05:17:58 +0000

As a Backend Engineer, I was always fascinated by Uber's magic 🎩 - how do they track millions of rides 🚗 in real-time with instant driver locations? I cracked the code, and this article reveals the core architecture behind it! ⚡

🏗️ The Architectural Thought Process

Let me break down Uber's real-time tracking system in a simple, visual way:

🔄 The Basic Workflow:

User Ride Accepted->Driver Location Got From Frontend->Backend Processes it -> Location Tracked Frontend

📡 What's Actually Being Sent?
When we say "location from frontend," here's the exact data flow:

let lastSentTime = 0;
navigator.geolocation.watchPosition((position) => {
    const now = Date.now();
    if (now - lastSentTime > 2000) { // Send every 2 seconds only
        socket.send(JSON.stringify({
            type: 'location_update',
            latitude: position.coords.latitude,
            longitude: position.coords.longitude
        }));
        lastSentTime = now;
    }
});

📦 Data Package Sent Every 2 Seconds:

type → Message identifier (location_update)
latitude → GPS latitude coordinate
longitude → GPS longitude coordinate

🗃️ Database Architecture Strategy

🚗 Continuous Location Data → NoSQL Database

Why? 📊

High Write Frequency → Every 2 seconds per driver
Simple Data Structure → Just coordinates + metadata
Scalability Needs → Millions of location updates daily

Uber's Choice: 🐙 Apache Cassandra
My Implementation: 🍃 MongoDB (for learning purposes)

👥 User & Business Data → SQL Database:
Why? 💼

Complex Relationships → Users, payments, ride history
ACID Compliance → Financial transactions need reliability
Structured Data → Well-defined schemas

Uber's Choice: 🐘 PostgreSQL
My Implementation: 🗃️ SQLite (for prototyping)

⚡ Real-Time Delivery System

📢 Pub/Sub Pattern for Instant Delivery

Uber's Production System: 🎯 Apache Kafka

Handles millions of messages per second
Fault-tolerant and highly durable
Perfect for global scale

My Learning Implementation: 🔴 Redis Pub/Sub

Lightweight and easy to set up
Great performance for learning projects
Demonstrates the same architectural principles

☁️ The Cloud Magic Behind Uber's Always-On System!:

What I haven't shown you yet is the cloud wizardry 🧙‍♂️ that makes Uber work flawlessly for millions! Here's the secret sauce:

🗺️ 1. Geographic Server Strategy - "City Zoning in Cloud!"
Why This Rocks: 🚀

No single server gets overloaded! ⚖️
Faster response times - your data doesn't travel across the city! 🏃‍♂️
If one zone has issues, others keep working! 🛡️

*🎪 2. Load Balancers - The "Traffic Police" of Internet! *:
What Load Balancers Do:

🎪 Distribute the circus - No single server does all the work!
🔄 Connection pooling - Reuse connections like UberPool! 🚗
❤️ Health checks - "You feeling okay, server?" 🏥

🎭 Understanding PUB/SUB Models - The Party Analogy! 🎉

🎭 Meet the Party Crew!

🎤 1. The Publisher - The Party Announcer:

Imagine someone with a megaphone at a massive festival. They don't know who's listening, they just shout out important updates! In Uber's world, this is the driver's phone constantly shouting "Here's my location!" every few seconds.

👂 2. The Subscriber - The Eager Listeners:
These are the party guests with their ears tuned to specific announcements. They're not interested in everything - just what matters to them! In our case, this is your phone eagerly waiting to hear where your driver is.

🚪 3. The Channel - Specialized Party Rooms:
Think of different rooms at a massive venue:

Room #ride_123 - Only people involved in that specific ride
Room #promotions - People interested in special offers
Room #emergency - Important safety updates You only enter the rooms you care about!

*✉️ 4. The Message - The Actual Announcement: *
This is the juicy information being passed around! It could be:

"Driver is 2 minutes away! 🚗"
"Surge pricing activated! ⚡"
"Your ride has arrived! 🎉"

🤵 5. The Broker - The Ultimate Party Planner:
This is the super-organized event coordinator who makes sure:

Every announcement reaches the right rooms
No messages get lost in the crowd
Everything runs smoothly behind the scenes.

🎯 The Uber Magic in Action:

Driver shouts 🗣️: "I'm at latitude X, longitude Y!"
Broker hears 👂 and knows exactly which ride channel this belongs to
Broker runs 🏃 to the specific ride room
Broker tells 📢 everyone in that room: "Driver is here!"
Your phone hears 📱 and shows you the moving car on map!

⚡ Why This Beats Shouting Individually:

The Old Way: Imagine running around a stadium telling each person individually about an update - you'd be exhausted! 😫

The PUB/SUB Way: Grab a megaphone, make one announcement, and everyone who needs to know hears it instantly! 🎤

🌟 The Beautiful Part:

Drivers don't need to know who's tracking them
Riders don't need to know which driver is sending updates
The broker handles all the complicated matchmaking behind the scenes
Everyone gets real-time updates without overwhelming the system

🏆 The Superpowers PUB/SUB Gives Uber:

🚀 Massive Scalability
One driver's location can be broadcast to thousands of riders simultaneously without slowing down!

🛡️ Reliability
If one rider loses connection, others keep receiving updates seamlessly

⚡ Lightning Speed
Messages travel at near-instant speed because there's no unnecessary processing

🎯 Precision Targeting
Only interested parties receive messages - no spam, no waste!

🎉 The Grand Finale:
Next time you watch that little car icon smoothly moving toward your location on Uber, remember there's an invisible party happening where:

Drivers are shouting their locations 🗣️
Your phone is listening intently 👂
A super-smart broker is running between rooms 🤵
And everyone stays perfectly coordinated without even knowing each other! ✨

That's the magic of PUB/SUB - making millions of simultaneous connections feel effortless! 🌟

🎯 Conclusion: Bridging Theory with Practice

🏗️ What We've Explored Together:

Throughout this journey, we've uncovered the architectural marvel that powers real-time applications like Uber. From the basic concept of live location tracking to the sophisticated Pub/Sub patterns that make it all possible at a massive scale - we've seen how modern systems handle millions of simultaneous connections seamlessly!

💻 Behind the Scenes: The Technical Implementation:
While this article focused on the conceptual architecture and system design principles, I actually built a complete working prototype using:

🐍 Python & Django - The Foundation

Django Models for structured data management
Django Channels for WebSocket magic
Redis Pub/Sub for lightning-fast message distribution
MongoDB for high-frequency location data storage

🔗 From Concept to Code:
The principles we discussed aren't just theoretical - they're battle-tested patterns that I implemented in a working Uber-like prototype. The same architectural thinking that powers global-scale applications can be implemented with the tools you already know!

👋 Keep Building, Keep Learning!:

Your journey into system architecture has just begun. Whether you're building the next Uber or working on your passion project, these principles will serve you well. The road to technical excellence is paved with solid architectural decisions!

🚀 Happy Coding, Future Architect! 🎉

Link to my github repo talking about it:
[(https://github.com/Meeth-webdev/uber-location_tracking-clone )]

Need Speed in Python? When to Use Threading vs. Multiprocessing.

Meeth Gangwar — Fri, 12 Sep 2025 17:53:53 +0000

🐢 Is your Python code stuck in the slow lane? What if you could tell it to stop waiting around and get more done? 🤔

The secret lies in the world of concurrency! While it's a deep and powerful topic, we're starting with a game-changer: the threading package. 🧵
In this article, we're diving deep into how you can use threading to supercharge your programs, making those sluggish I/O operations—like downloading files, reading databases, or calling APIs—blazingly fast! ⚡

Get ready to unlock a new level of performance. Let's untangle the threads! 🔓

🤔 What on Earth are Processes & Threads?

Let's break it down without the scary jargon!

Imagine your computer is a giant kitchen 🧑🍳👩🍳. This kitchen's goal is to cook meals (aka run your programs).

What's a PROCESS? 🍳

Technical Jargon Buster: A process is an instance of a program.

Fun Explanation:
A process is like a single chefgetting a recipe and their own private kitchen station to work in. This station has its own oven, bowls, ingredients, and tools. No other chef can use them!

My laptop has 4 CPUs? That means my kitchen has 4 separate stations. So, 4 chefs can cook 4 different recipes (processes) at the exact same time! More stations (CPUs) = more chefs working = a faster kitchen! 🚀

The Catch: Hiring a new chef and building them a whole new station (creating a process) takes a lot of time and effort. It's powerful, but not always the quickest solution.

What's a THREAD? 🧵

Technical Jargon Buster: A thread is an entity within a process that can be scheduled.

Fun Explanation:
A thread is like a single task a chef is doing. One chef (process) can have multiple threads! They can be chopping veggies 🥕 (thread 1) while the water is boiling 💨 (thread 2).

They Share Everything! All the threads (tasks) for one chef share the same station—the same oven, the same bowl of sugar, the same knives. This makes it super easy for them to collaborate!
It's Super Efficient! Telling your chef to start another task (creating a thread) is way faster than hiring a whole new chef and building a new station (creating a process).

🚨 The Python Plot Twist: The GIL (Global Interpreter Lock)
So if threads are so great, why isn't Python code lightning fast all the time? Enter the GIL, Python's quirky bodyguard. 🕵️‍♂️

Imagine our chef is using a single, magical recipe book. The GIL is a rule that says:

"Only ONE hand (thread) can turn the pages of the recipe book at a time!" 📖➡️🤚

Why? To prevent chaos! If two hands tried to read and change the recipe at the same time, the instructions could get messed up (this is called a race condition and it corrupts data).
The Result: Even though our chef can do multiple tasks, they can only follow one step from the recipe at any single moment. They quickly switch between tasks—chopping, then stirring, then checking the oven—so fast it feels simultaneous, but it's not truly parallel.

So, if the GIL only allows one thread at a time... why do we even use threads in Python? 🤯

Ah-ha! That's the million-dollar question! The answer is the key to unlocking real speed in your programs.

Stay tuned for the next section, where we'll crack the GIL's code and learn exactly when threading makes Python FLY! ⚡

🏁 Understanding Multithreading with a Classic Example! 🧵⚡

Hey everyone! Let's break down this classic example of multithreading in Python. It demonstrates a common pitfall and its superhero solution: the Lock. 🦸‍♂️

But first, hold on! Let's understand the villain of our story...

🤯 What is a Race Condition?
Imagine a race condition is like two people trying to update the same Google Doc cell at the exact same time. ✍️💥

Person A reads the number: 0.

Person B also reads the number: 0 (before Person A can save their change).

Person A adds 1 and saves: the doc now says 1.

Person B adds 1 and saves: the doc overwrites Person A's work and now says 1.

Final result: 1
Expected result: 2 (because two people each added 1)

This chaos is exactly what happens between threads! They "race" to update a shared resource, and the result is incorrect. Our code above brilliantly replicates this chaos and shows us how to fix it!

🔎 Code Breakdown: Taming the Race

The Guardian of the Gate: if name == 'main': This isn't just a random line—it's a security guard for your code! 🛡️

name is a special Python variable.

When you run the file directly (python script.py), Python sets name to 'main'.
If someone imports your script as a module, name becomes the module's name.

So, this line means: "Only run the code below if this is the main file being executed, not if it's being imported." This is a crucial best practice, especially with threads!

2.** The Mission: The increase() Function**
This function has one job: grab the shared database_value, add 1 to it, and put it back. Simple, right? Not when two threads are doing it at once!

Summoning the Threads: The Cast of Characters

thread1 = Thread(target=increase, args=(lock,))
thread2 = Thread(target=increase, args=(lock,))
Thread(): This is how we create a new thread (a new worker). 🧑💻🧑💻

target=increase: Tells the thread which function to run.

args=(lock,): Passes the same Lock object to both threads. Heads up! The comma inside (lock,) is essential. It tells Python it's a tuple with one item. Without it, it's just lock in parentheses.

2)Understanding the code inside the increase function:
The increase function is a function which we have defined and this function basically what it does is that it helps in increasing the value of the database by 1 .
Now the important part is inside the if statement the part where we wrote
thread1=Thread(target=increase,args=(lock,))
thread2=Thread(target=increase,args=(lock,))
this makes sure that there are two threads thread1 and thread2 and these both the threads are aimed to the target function!

🎭 Act 1: The Problem (No Lock = Chaos!)
Let's play out the scenario WITHOUT the lock.acquire() and lock.release() lines:

Thread 1 enters the increase() function.
It reads database_value (0) into its local_copy.
It increments local_copy to 1.
time.sleep(0.1) is called! 😴 Thread 1 hits the pause button and goes to sleep.
The operating system sees Thread 1 is sleeping and switches to Thread
Thread 2 enters the increase() function.
It reads database_value (which is still 0 because Thread 1 hasn't saved yet!).
It increments its local_copy to 1.
time.sleep(0.1) is called! 😴 Thread 2 also goes to sleep.
Thread 1 wakes up and saves its value (1) to database_value.
Thread 2 wakes up and saves its value (1) to database_value, overwriting the update from Thread 1!

The Final Tragedy: database_value = 1 ❌
What we wanted: database_value = 2 ✅
This is the infamous race condition!

🦸‍♂️ Act 2: The Solution (With Lock = Order!)
Now, let's use the Lock! The lock.acquire() and lock.release() lines are the heroes.

Thread 1 enters the function and immediately calls lock.acquire(). It grabs the lock! 🔒 "It's my turn!"
It does its work (read, increment) and then goes to sleep. It still holds the lock while sleeping.
Thread 2 enters the function and tries to call lock.acquire(). 🚫 The lock is taken! Thread 2 is now BLOCKED and forced to wait.
Thread 1 wakes up, saves the value (1), and calls lock.release(), freeing the lock. 🔓 "I'm done!"
Thread 2, which was waiting, can now acquire the lock and proceed.
Thread 2 reads database_value (which is now correctly 1).
It increments it to 2, sleeps, and saves the result.

The Victory: database_value = 2 ✅

🎯 Key Takeaway

time.sleep(0.1) mocks a real-world slow operation (like waiting for a database response or a network API call). 🌐

The Lock ensures that only one thread at a time can execute the critical section of code (the part that touches the shared data).

Correctness is maintained because the lock forces threads to wait for their turn, preventing them from reading dirty or intermediate data.

Using a Lock is like giving a single key to a shared room. Only the person with the key can enter and use the room. Everyone else has to wait outside until the key is returned! 🗝️

🧠 Leveling Up: Threading vs. Async Await - Why Learn Both?

First off, pat yourself on the back! 👏 If you looked at the threading example and thought, "Hang on, this feels familiar... isn't this what async/await does?", then you're already thinking like a senior engineer. That's an incredible connection to make!

You're absolutely right. Threading and Async both solve the same core problem: making I/O-bound code faster. They are two different tools from the toolbox, both designed to stop your program from sitting idle, twiddling its thumbs, while it waits for slow external services (databases, APIs, file systems). ⏳➡️⚡

But they are not the same thing. Let's break down the "why".

🏗️** The Great Illusion: How Do They Work?**
Imagine threading is like hiring multiple chefs for a kitchen.

1. The OS is the kitchen manager. It has the power to force a chef to stop chopping veggies immediately and put another chef on the stove. This is called preemptive multitasking.
2. It's powerful but heavy. Each new chef (thread) needs their own set of resources and space. Switching between them (context switching) takes time and effort.
3. There's always overhead in communication (like our Lock) to make sure they don't burn the same sauce.

Async: The "Single Master Chef" Approach 🧙‍♂️ Now, imagine async is a single, incredibly efficient master chef.

This chef starts a task (e.g., putting water on to boil). Instead of waiting and staring at the pot, they immediately check the recipe book to see what else they can do (e.g., chop vegetables). 🥕
They are cooperatively switching tasks. They themselves decide when to pause one task and switch to another. This is called cooperative multitasking.
It's incredibly lightweight. There's only one chef, so no communication overhead, no context switching cost. But it requires every task to be well-behaved and say "I'm going to wait now, someone else can go."

https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q2df5ohuhjtrvcet90sp.webp
This image perfectly shows the difference: Threading uses multiple OS-managed threads (multiple lanes of traffic with a traffic cop), while Async uses a single thread with cooperative scheduling (cars politely yielding to each other on a single lane).

🤔 So Why Did We Just Spend Time Learning Threading?!
This is the million-dollar question! If Async is so lightweight and efficient, why does threading even exist? Here’s the deal:

🧪 The Legacy Codebase Reality
You hit the nail on the head. The world runs on legacy code. Mountains of enterprise software, scripts, and systems were built before asyncio became mature in Python. These systems use threading and it works. Rewriting them entirely in async would be a massive, expensive, and risky project. Understanding threading is essential for maintaining and updating a huge portion of the software that powers the world today.
🛠️ The Right Tool for the Job
While async is fantastic for I/O-bound tasks (network calls, file ops), threading can also handle CPU-bound tasks that can truly run in parallel on multiple cores... if you can avoid the GIL. How? By using multiprocessing (which creates separate processes) or by offloading heavy number-crunching to libraries like numpy that release the GIL. Async can't do that.
🧠 Conceptual Foundation
Threading teaches you the fundamental problems of concurrency. 🎓

Race Conditions
Deadlocks
Locks & Synchronization
Shared State

These are universal concepts. If you understand the pain of managing a Lock() in threading, you deeply understand why async was invented to avoid that pain. It makes you a better async programmer because you know what problems it's solving under the hood.

⚔️ It's Not a Total Replacement There are scenarios where threading is still a simpler or more appropriate solution than a full async framework, especially for simpler scripts or when you need to run background tasks in a framework like Django that isn't built on async.

So, you learned threading not just to use it, but to understand the core problem. You now know why modern tools like Async were created. It's like learning to drive a manual transmission before an automatic—it gives you a deeper understanding of how the engine works, making you a better driver overall.

Think of it this way: Threading is the theory. Async is one of the modern applications of that theory. You can't truly master one without understanding the other. 🚀

🎉 Conclusion & What's Next?

And... that's a wrap! 🎬

A massive thank you for joining me on this deep dive into the world of Python threading. 🙏 Your time and curiosity are what make writing this so rewarding. I truly hope you're walking away with that satisfying "Aha! 💡" feeling and some new tools for your coding toolkit.

🚀 Your Coding Superpower
You've just leveled up. You now understand a concept that trips up many developers. The next time you see a Lock() or hear about a "race condition," you can nod knowingly instead of sweating nervously. That's a big win!

🔜 What's on the Horizon?
We've mastered the concurrency puzzle with threading, but the adventure doesn't stop here! The world of parallel execution in Python has more exciting chapters:

⚡ Multiprocessing: The true key to unlocking the full power of your multi-core CPU for CPU-bound tasks (like number crunching or image processing), completely bypassing the GIL!
🤖 The Async Await Universe: A deeper look into the modern, lightweight alternative to threading for I/O-bound chaos.
🧠 Advanced Threading Patterns: Exploring thread pools, queues, and other sophisticated ways to manage your threads like a pro.

Each of these is a fascinating topic in itself, and I can't wait to explore them with you in future articles!

Keep the Connection Alive!
As always, I'll be here, constantly breaking down complex tech topics into bite-sized, fun-to-learn pieces. Stay tuned for more articles daily!

Until the next one, happy coding! May your bugs be minor and your coffee be strong. ☕

Cheers,
Meeth
Backend Engineer

Throughput vs. Latency: The Optimization Dilemma

Meeth Gangwar — Sun, 31 Aug 2025 10:51:13 +0000

"You've just deployed your new feature. It's getting traffic, but users are complaining that the app 'feels slow.' You check your metrics: your server is handling thousands of requests per second (high throughput!), so why is the user experience so poor?

This, right here, is the classic clash between Throughput and Latency. Understanding their difference isn't just academic—it's the key to unlocking a faster, more scalable application."

Throughput vs. Latency: Do You Really Know the Difference??!! 🤔

Alright, let's cut through the tech jargon! 🪚

According to the definition:
Throughput is how much data your system can handle over a certain period of time. 📦📦📦
Latency is how quick a single piece of data is received after a client asks for it. ⚡

Still too technical? Let's break it down with a simple example.

Imagine a CPU is a Barista ☕ in a coffee shop. Now:

Throughput is the total number of orders the barista can complete in an hour. → "How many coffees per hour?" 🏃‍♂️💨

Latency is the time you wait in line to get your coffee after you place your order. → "How long until my first sip?" ⌚😤

But wait! You might have a question...

How do throughput and latency vary with each other??

This is the part that is confused by so many, including me when I first learned it! 🤯

The answer is not what you might think, and it's the key to understanding system performance. We will explore exactly how one affects the other in the next paragraph, using this same coffee example. Stay tuned!

How Do Throughput & Latency Depend on Each Other? 🤝

Let's dive back into Barista Ben's coffee shop! ☕ We left off wondering how these two concepts interact. Well, get ready, because the answer is fascinating!

Scene 1: The Quiet Morning 🍃
The Scene: It's early. Only a few customers trickle in. There's no line.

The Result: You walk right up, order your latte, and get it almost immediately! 🚀

Latency is super low!

The Catch: But poor Ben is often just... waiting. He's not making many coffees per hour. 😴

Throughput is low.

The Tech Translation: Your system has plenty of free resources. Responses are lightning-fast ⚡, but your expensive servers are sitting idle, which is inefficient

Scene 2: The Balanced Lunch Rush 🎯

The Scene: It's noon! A steady stream of customers forms a short, moving line.
The Result: You wait a few minutes for your coffee—a totally reasonable delay. ⏱️

Latency is a bit higher, but still good.

The Catch: Ben is constantly working! He's pumping out orders at an excellent, sustainable pace. 👨🍳💨

Throughput is high and efficient!

The Tech Translation: This is the Sweet Spot! 🎯 Your system is fully utilized but not overwhelmed. You're serving the maximum number of users without making anyone excessively angry. This is the ideal state for any system.

Scene 3: The Chaotic Afternoon Nightmare 😱

- The Scene: A conference let out and everyone rushed in. The line is out the door!
- The Result: You might wait 20, 30, even 45 minutes! Your coffee is cold by the time you get it. ❄️😤 Latency is skyrocketing! -** The Catch**: Ben is working at absolute breakneck speed, sweating bullets! He's making more coffees than ever... but the line just keeps growing! 💦 Throughput has maxed out and may even start to fall as Ben gets overwhelmed and makes mistakes.
The Tech Translation: Your system is overloaded. 🚨 Users are experiencing timeouts and errors. Even though the server is at 100% CPU, everyone is having a terrible experience. This is a critical failure state.

Now that you've mastered the difference, a huge question must be burning in your mind... 🔥

If this happens in my software, what do I do?! How do I fix high latency? How do I increase throughput?
Do I... *optimize my API code?_ 🧑‍💻
Do I... *add more indexes to the database?_ 🗃️
Do I... *add more servers?!_ 🖥️🖥️🖥️
The secrets to controlling throughput and taming latency are coming up next... and the answers might surprise you!

Optimizing Latency & Throughput: The Hunt for the Sweet Spot! 🎯

So, you've built your API. It works. But now the big question hits:

How do you make it blazingly fast and massively scalable? How do you find that perfect sweet spot where you're serving the maximum number of users without them ever complaining about speed? 🤔

Let's unlock the secrets! 🔑

The Golden Rule: First, Measure Everything! 📊

You can't optimize what you can't measure. Before you change a single line of code, you need to know your starting point.

What's your current latency? (Are users waiting 100ms or 10 seconds? ⏳)
What's your current throughput? (Can you handle 10 requests/second or 10,000? 📦)

This is where the magic of load testing comes in! We use tools like k6 or JMeter to purposely simulate traffic—from a trickle to a tsunami—and see exactly how our system behaves under pressure. It's like a stress test for your code! 💻🌊

How to Improve Throughput: The Three Pillars 🏛️

Think of your application as a pipeline. To increase the flow (throughput), you need to widen the narrowest point. Here’s how:

*Database Throughput *(QPS - Queries Per Second) 🗄️⚡
Your database is often the #1 bottleneck. Here’s how to supercharge it:

Indexing: 🧭 Imagine this: finding a name in a phonebook vs. reading every page. Indexes are that phonebook directory for your database, helping it find data instantly.

Query Optimization: 🔍 Use EXPLAIN ANALYZE to find those lazy, slow queries and whip them into shape! A single bad query can drag your entire app down.

Read Replicas: 🐑 If your app is read-heavy (like a blog), why make one database do all the work? Create clones (read replicas) to distribute the reading load!

Sharding: ➗ The ultimate power-up! Split your massive database into smaller, more manageable pieces (e.g., put users A-M on one server and N-Z on another). This is how the giants like Google scale.

B)** Server Throughput** (RPS - Requests Per Second) 🖥️🔥
This is about your application code and the servers it runs on.

Scale Horizontally (Scale-Out): 👯👯👯 Don't just get a bigger server. Get more servers! Put them behind a load balancer to distribute traffic evenly. This is the core of cloud scalability.

_Scale Vertically _(Scale-Up): 💪 Sometimes, you just need a bigger machine. More CPU, more RAM. Simple, but has limits.

Code Efficiency: ✨ Is your code full of lazy loops? Are you using the right data structures? Clean, efficient algorithms are like giving your server a turbo boost.

C) Data Throughput (The Network Pipe) 🌐➡️🔄
This is about the speed of data itself.

Caching: 🗃️⚡ Why ask the database the same question 100 times? Store frequent answers in a lightning-fast Redis or Memcached store. This is the #1 win for performance!

_Content Delivery Network _(CDN): 🗺️ Why serve a profile picture from India to a user in Canada? A CDN caches your static files (images, CSS, JS) on servers around the world, so they load in a blink.

The Million-Dollar Question: How Do You Find The SWEET SPOT? 🎯

Ah-ha! This is where engineering becomes an art.

1)*Define Your SLOs *(Service Level Objectives): 🤝 This is your promise to users. "I promise that 99% of our API requests will respond in under 200 milliseconds." If you break this promise, there are repercussions. This defines what "acceptable latency" is for your business.

2)Perform Load Testing: 🧪🔬 This is how you test your promise! You deliberately overload your system with tools like k6 to answer:
"At what number of RPS does our latency start to exceed our 200ms SLO?"

That exact point—your maximum throughput before breaking the promise—is your sweet spot!

3)Understand the Bottleneck: 🕵️‍♂️ When your test fails, you don't just guess. You investigate!
Is the database CPU maxed out at 100%? → Time to optimize queries or shard.
Are your application servers out of memory? → Time to scale horizontally or fix memory leaks.
Is the network bandwidth saturated? → Time to compress data or use a CDN.
The cycle never ends: Measure → Identify Bottleneck → Optimize → Measure Again.
This is the flywheel of a performance engineer! 🚴‍♂️💨

Conclusion: The Never-Ending Quest for Scale 🔁

So, you've found your sweet spot. You've defined your SLOs, optimized your queries, and scaled your servers. You're feeling confident.

But the true test doesn't happen in a controlled load test. It happens at 3 AM when your app goes viral and traffic explodes by 100x overnight. 😨

This is where the real engineering begins. The journey to true scalability isn't a destination you arrive at; it's a continuous cycle of anticipation, testing, breaking, and optimizing.

Your system will break. The question is not if, but when and where.
Will it be your database, brought to its knees by a flood of queries? 🗄️💥
Will it be your application servers, crashing under the weight of a thousand simultaneous requests? 🖥️🔥
Or will it be a hidden dependency, a tiny third-party API that becomes the single point of failure in your entire architecture? 🔗⛓️

This endless challenge—this relentless pursuit of performance and resilience—is what makes backend engineering so thrilling. It's a high-stakes game of architectural chess against unpredictable demand.

So, tell me: What part of your system do you think would break first?

Let me know in the comments! 👇

MEETH
Backend Engineer