DEV Community: raghvendra dixit

Design WhatsApp Like a Kirana Store

raghvendra dixit — Tue, 27 Jan 2026 11:39:07 +0000

Interview Question:

Design WhatsApp.

Big system. Huge scale.

Instead of panicking, think small.

Think of a kirana store.

🏪 Meet Ramesh

Ramesh runs a kirana store in a small locality.

He doesn’t know system design — but he thinks correctly.

We will design WhatsApp using his thinking.

1️⃣ How many people will come (Users & Traffic)?

Kirana Store

People nearby: 1,000
Customers per day: 200
200 customers per day

WhatsApp (assumption)

Daily Active Users: 500 million
Messages per user per day: 40
500,000,000 × 40 = 20,000,000,000 messages per day

2️⃣ When is the rush (Peak Load)?

Kirana Store

Shop open: 12 hours
Evening rush: 60% customers
120 customers in 3 hours = 40 customers per hour (peak)

Engineers assume:
Peak traffic = 5 × average traffic

Systems break at peak, not average.

3️⃣ Do people ask more or buy more (Read vs Write)?

Kirana Store

Out of 200 customers:
Read : Write = 80 : 20

One message write causes many reads (delivery, sync, notifications).

Same ratio. Bigger scale.

4️⃣ What stays near the counter (Cache / Memory)?

Kirana Store

Fast items near counter:

Sugar: 5 kg
Biscuits: 20 packets
Milk: 10 packets

Slow items go to the storeroom.

Assumptions:

Hot users: 20%
Recent chat data per user: 2 KB
100,000,000 users × 2 KB = 200 GB cache

Hot data in memory. Cold data in database.

5️⃣ How much storage is needed (Data Size)?

Kirana Store

20 customers × 1 kg sugar = 20 kg per day

Assumptions:

Average message size: 500 bytes
Messages per day: 20 billion 20,000,000,000 × 500 bytes = 10 TB per day With replication: 10 TB × 3 = 30 TB per day

6️⃣ One notebook or many (Database Choice)?

Kirana Store

One notebook for daily sales
One notebook for credit customers

Messages → NoSQL
User info → SQL
Media → Object storage + CDN

Access pattern decides storage.

7️⃣ Should slow work happen during rush (Async & Queues)?

Kirana Store

During rush, Ramesh:

Does not count stock
Does not call suppliers

During peak:

Notifications
Media processing
Fan-out delivery

All done asynchronously.

🧠 Final Thought

Ramesh:

Counts people
Plans for rush
Keeps fast things close
Pushes slow work away

That is system design.

🏁 One Line to Remember

Design WhatsApp like a kirana store — count users, design for peak, cache hot data, and move slow work off the critical path.

Customers Don’t Build Cars. Developers Shouldn’t Build Objects.

raghvendra dixit — Fri, 16 Jan 2026 07:06:35 +0000

You Don’t Order a Car Engine. You Order a Car.

When you go to buy a car, you don’t say:

Give me a V8 engine, four doors, ABS brakes, and leather seats.

You say:

I want a Sedan.

Or:

I want an SUV.

And the factory handles the rest.

That’s the Factory Pattern.

The Real-Life Problem

Imagine if buying a car worked like this:

new Engine();
new Wheels();
new Brakes();
new Seats();

Every customer would need to understand:

Engine types
Safety systems
Assembly rules

That would be chaos.This is exactly what happens in software when business code creates objects directly.

What the Factory Actually Does

A car factory hides complexity.

You ask for:

Sedan
SUV
Hatchback

The factory decides:

Which engine to use
How many parts are needed
How everything fits together

You get a ready-to-use product.

Factory Pattern in One Sentence

Client asks for a type. Factory returns a ready object. Client never uses new.
That’s it.

Why Your Brain Remembers This?

Because the rule is simple:

Customers don’t build cars
Developers shouldn’t build objects Both ask a factory.

The One Line You’ll Never Forget

If users choose products, use a Factory.

Final Thought

Singleton answers:

How many objects should exist?

Factory answers:

Which object should I give you?

Once you see the car factory, you’ll never forget the Factory Pattern again.

Customers Don’t Build Cars. Developers Shouldn’t Build Objects.

raghvendra dixit — Fri, 16 Jan 2026 07:06:35 +0000

You Don’t Order a Car Engine. You Order a Car.

When you go to buy a car, you don’t say:

Give me a V8 engine, four doors, ABS brakes, and leather seats.

You say:

I want a Sedan.

Or:

I want an SUV.

And the factory handles the rest.

That’s the Factory Pattern.

The Real-Life Problem

Imagine if buying a car worked like this:

new Engine();
new Wheels();
new Brakes();
new Seats();

Every customer would need to understand:

Engine types
Safety systems
Assembly rules

That would be chaos.This is exactly what happens in software when business code creates objects directly.

What the Factory Actually Does

A car factory hides complexity.

You ask for:

Sedan
SUV
Hatchback

The factory decides:

Which engine to use
How many parts are needed
How everything fits together

You get a ready-to-use product.

Factory Pattern in One Sentence

Client asks for a type. Factory returns a ready object. Client never uses new.
That’s it.

Why Your Brain Remembers This?

Because the rule is simple:

Customers don’t build cars
Developers shouldn’t build objects Both ask a factory.

The One Line You’ll Never Forget

If users choose products, use a Factory.

Final Thought

Singleton answers:

How many objects should exist?

Factory answers:

Which object should I give you?

Once you see the car factory, you’ll never forget the Factory Pattern again.

❌ Stop Using Singleton. You Don’t Need It (And It’s Quietly Hurting Your Code)

raghvendra dixit — Fri, 16 Jan 2026 06:07:13 +0000

Stop Using the Singleton Pattern

The Singleton pattern looks simple and useful.

It is also one of the most common causes of hidden design problems in software systems.

What Singleton Does

Singleton ensures that a class has only one instance and that this instance can be accessed globally.

Logger.getInstance().log("Hello");

One instance. Global access.

The Real Issue

Singleton is just global state.

Any part of the code can access it, change it, and depend on it without being explicit. This makes systems harder to understand, test, and change.

Why Senior Engineers Avoid It

Singleton often causes:

Hidden dependencies
Difficult unit testing
State leaking across requests
Tight coupling between classes

What looks convenient early becomes technical debt later.

A Better Approach

Instead of accessing global objects, pass dependencies explicitly.

This makes dependencies visible, code easier to test, and systems more flexible.

A Simple Rule

If passing a dependency feels annoying, the solution is better design — not a Singleton.

# 🎭 How I Learned Database Selection Through a Shakespearean Story

raghvendra dixit — Tue, 13 Jan 2026 11:24:10 +0000

I often struggle to remember which database fits which use case — relational, document, key-value, graph, time-series.

Memorising rules never worked for me.

So instead, I turned database selection into a short comic-style story inspired by Shakespeare.

Surprisingly, this made system design concepts stick far better than any cheat sheet.

Curious to know how this approach feels to others.

Scene: A Julius Caesar play. Brutus and Cassius whisper on stage.

🎭 Act I: The Database Selection Problem

Brutus:

Cassius, before we stab Caesar… a question.

Which database should Rome use?

🎭 Act II: Why Memorization Fails

Cassius:

Good Brutus, must thou memorise all databases?

Brutus:

I tried.

They flee my mind faster than loyalty in Rome.

🎭 Act III: Mapping Problems to Databases

Cassius:

Then answer me this — where lies Rome’s gold?

Brutus:

In a vault.

No errors permitted.

Cassius:

There stands thy relational database.

Where a single mistake is treason.

Brutus:

And the citizens?

Ever changing, oddly shaped?

Cassius:

A cupboard of chaos —

a document database.

Brutus:

When a guard cries,

“Water, now!”

Cassius:

No thought.

Only speed.

A key-value store.

Brutus:

And when one asks,

“Knowest thou a good carpenter?”

Cassius:

A friend of a friend of a friend.

A graph database.

Brutus:

Daily costs of war,

tallied by time?

Cassius:

A ledger.

A time-series database.

🎭 Act IV: The Core Lesson of Database Selection

Brutus:

So the lesson?

Cassius:

Choose not the database first —

choose the problem.

Brutus:

Et tu, database confusion?

(Exeunt. Applause.) 👏

🧠 Why Storytelling Works for System Design

I stopped memorizing database definitions
I started remembering real-world situations
Each database became a scene, not a rule

Turns out, the human brain remembers stories far better than tables.

💬 What Do You Think?

Does this storytelling approach help you remember database selection better?

Or do you prefer traditional system design explanations?

Would love to hear your thoughts 👇