DEV Community: Sreya Satheesh

What Happens When You Send a WhatsApp Message?

Sreya Satheesh — Sat, 03 Oct 2026 11:18:17 +0000

We use WhatsApp every day.

Send a message.
See the ticks.
Get a reply.

It is easy to think of messaging as something that happens directly between two phones.

But there is a whole system between them.

Where does the message go after you tap Send?

How does WhatsApp find the person you're messaging?

What happens if they are offline?

How does one tick become two?

What happens when the same message is received twice?

And what changes when millions of people are sending messages at the same time?

Those questions became What's Up?

Start with one message

I wanted to build a different kind of system design visualizer.

Instead of starting with a large architecture diagram, I started with a WhatsApp chat.

Eva sends Sam:

Hey 👋

The message leaves Eva's phone.

From there, the app lets you follow what happens inside a messaging system.

The message reaches a server.

Sam's connection may be sitting on another server.

The system needs to find it.

If Sam is offline, the message needs to be stored until he comes back.

When he reconnects, the message can be delivered.

Then there is another question:

How does Eva know it was delivered?

And how does she know Sam actually read it?

The familiar ticks on WhatsApp represent a much larger system underneath.

What if something goes wrong?

A message can be sent again.

An acknowledgement can be lost.

A server can fail.

A connection can disappear.

If a request is retried, the system has to deal with the possibility that the same message has arrived more than once.

That is where things like message IDs and deduplication become important.

The app lets you break parts of the system and see what changes when they are missing.

Instead of only reading that a component is needed, you can see the problem it was solving.

What about photos and videos?

A WhatsApp message isn't always text.

Photos and videos are much larger.

So the system needs another path for media.

Object storage can hold the actual file.

A CDN can help deliver it.

The message itself can carry the information needed to find that media.

One chat can therefore involve several different services, depending on what is being sent.

What changes in a group?

A message to Sam is one thing.

A message to a group is different.

One message may need to reach many people.

Now the system has to deal with group membership, fan-out, queues and delivery at a larger scale.

The same small chat bubble creates a different problem once there are many recipients.

Where is everyone?

WhatsApp also shows things like online status and last seen.

That creates another question for the system:

How does it know whether Sam is online?

A presence system needs to keep track of changing connections without turning every small status change into an expensive operation.

Again, something that looks like a tiny piece of the WhatsApp interface has a system behind it.

Then there is scale

Two people sending messages is easy to picture.

WhatsApp has billions of users, so the system cannot depend on one server or one database.

Connections need to be distributed.

Messages need to be routed.

Data needs to be partitioned and replicated.

Queues can separate pieces of work.

Services need to keep working when individual servers fail.

The architecture grows from the questions.

And security?

A messaging system also has to answer a much more important question:

Who can read the message?

The design needs to account for encryption and, for WhatsApp, end-to-end encryption as part of the security model.

That adds another boundary to the system.

The message still needs to travel through the infrastructure.

The infrastructure should not simply become a place where the message can be read.

That's what I wanted to show

What's Up? is a visual walkthrough of how a WhatsApp-style messaging system can be designed.

It starts with one message and gradually introduces the pieces needed to make messaging work:

WebSockets for persistent connections
connection management
message routing
offline storage
delivery and read acknowledgements
retries and deduplication
media storage and CDNs
group messaging
queues
presence
databases
partitioning and replication
scaling
encryption

There isn't one giant diagram waiting at the beginning.

The architecture appears as the questions appear.

You start with:

Hey 👋

And by the end, you can see the system that had to exist for those two words to reach the other side.

What's Up?

That's the question behind the name too.

What's up after you press Send?

Quite a bit.

👉 Try What's Up?

The One Time Password

Sreya Satheesh — Thu, 01 Oct 2026 07:34:25 +0000

👉 Try The One Time Password

We've all entered an OTP before.

Six digits. Enter. Verify. Done.

But what happens behind those six digits?

Where is the OTP generated?

Where is it stored?

How does it expire?

What happens when someone enters the wrong code?

And what happens when millions of users need an OTP at the same time?

I built The One Time Password to explore these questions.

What Is It?

The One Time Password is an interactive walkthrough of how an OTP service can be designed.

Instead of showing the whole system as one architecture diagram, the app lets you follow a request through each part of it.

A simplified flow looks like this:

User → API → OTP Service → Redis → Delivery Provider → User → Verification

The user requests an OTP.

The service generates one, stores it with an expiration time, and sends it to the user.

The user enters the code.

The service checks it and returns the result.

What Happens to the OTP?

An OTP is temporary, so the system needs to keep track of a few things:

The code
Who requested it
How long it is valid
Whether it has already been used
How many verification attempts have been made

For the temporary storage, the design uses Redis.

An OTP can be stored with a TTL (time-to-live):

Generate OTP
     ↓
Store OTP + TTL
     ↓
Send OTP
     ↓
User enters OTP
     ↓
Verify
     ↓
Success → Invalidate
Expired → Reject

Once the TTL expires, Redis removes the entry.

The Security Part

A six-digit OTP has only a limited number of possible combinations.

So generating the code is only one part of the problem.

The service also needs to handle:

Rate limiting
Brute-force attempts
Resending OTPs
Replay attempts
OTP expiration
Secure random generation
Preventing an OTP from being reused

For example, what should happen if someone keeps trying different codes?

Or keeps requesting new OTPs?

These are the kinds of cases the system needs to account for.

What Happens at Scale?

Now take the same service and give it millions of users.

A few more questions come up:

Can multiple application servers handle the requests?
How do they share OTP state?
What happens if Redis goes down?
What happens if the SMS or email provider is slow?
What happens when a request is retried?
How should repeated OTP requests be handled?

The six-digit code is straightforward.

The system around it is where most of the design decisions are.

Inside the App

The walkthrough covers:

OTP generation
Redis
TTL and expiration
Verification
Rate limiting
Security
Scaling
Retries
Failures
System architecture

You can move through the request and see how these pieces connect.

Try It Yourself

👉 The One Time Password

Start with an OTP request and follow it through the system.

Behind Every 429 Too Many Requests

Sreya Satheesh — Thu, 18 Jun 2026 08:05:53 +0000

👉 https://rate-limiter-two.vercel.app/

Most developers have seen this message before:

429 Too Many Requests

A request gets rejected because a limit has been reached.

But what actually happens behind the scenes?

How does the system know you've made too many requests?

Where are those requests counted?

What happens when millions of users are sending requests at the same time?

Those questions got me interested in rate limiter design.

What Is a Rate Limiter?

A rate limiter controls how many requests a user, client, or service can make within a given period of time.

You'll find them almost everywhere:

APIs
Authentication systems
Payment services
AI applications
Public platforms

Without rate limiting, a single user or script could overwhelm a system with requests.

Why Does Designing One Matter?

A simple rate limiter might work for a small application.

Things become more interesting when the traffic grows.

Where should request counts be stored?

How much data needs to be maintained?

How many requests should the system handle every second?

How do multiple servers share the same limits?

Answering those questions is where system design comes in.

Breaking Down the Design

The project covers the different stages involved in designing a rate limiter:

Functional Requirements
Non-Functional Requirements
Capacity Estimation
High-Level Design

Each section builds on the previous one.

Requirements influence the scale.

Scale influences the architecture.

And the architecture influences the implementation choices.

High-Level Design

Once the requirements and scale are clear, the architecture becomes much easier to understand.

The High-Level Design section explains the major components involved and how requests move through the system.

What's Next?

Algorithms and race conditions are currently being added.

Future updates will cover:

Fixed Window
Sliding Window
Token Bucket
Leaky Bucket
Distributed rate limiting challenges

👉 https://rate-limiter-two.vercel.app/

What If DSA Was Taught Visually Instead of Just Theory?

Sreya Satheesh — Thu, 11 Jun 2026 05:45:07 +0000

👉 https://www.decoded-app.com/

When learning DSA, it's easy to fall into a familiar cycle.

You solve a problem, understand the solution, and move on.

A few days later, you come across a similar problem—and suddenly it feels unfamiliar again.

The frustrating part is that you did understand the solution.

What often doesn't stick is the reasoning behind it.

How do you know where to start?

How do you recognize patterns?

How do you arrive at an efficient approach before writing any code?

Those questions are what led me to build Decoded.

What is Decoded?

Decoded is a small app focused on helping people understand how DSA problems are approached, not just how they're solved.

Instead of jumping straight to the final solution, it breaks problems down step by step.

The goal is to show:

how you begin thinking about a problem
how patterns start becoming visible
how an approach gradually forms
and how the final solution evolves from there

Rather than memorizing answers, the focus is on understanding the path that leads to them.

See Algorithms in Action

One feature I found especially useful while learning was seeing algorithms unfold visually.

So Decoded includes step-by-step dry runs that show how variables, pointers, and state change throughout execution.

For example, in the Longest Substring Without Repeating Characters problem, you can watch the sliding window expand and shrink as duplicate characters are encountered.

" width="800" height="373">

Instead of reading through a static explanation, you can follow the algorithm's behavior step by step and see exactly why each decision is made.

The goal is to make the process feel less abstract and easier to follow.

Learning Patterns Instead of Memorizing Problems

One thing I noticed while studying DSA is that most problems aren't completely unique.

Many of them are variations of a handful of recurring patterns:

Sliding Window
Two Pointers
Prefix Sum
DFS / BFS
Heaps
Dynamic Programming and more

" width="799" height="370">

Once you start recognizing these patterns, solving problems becomes much easier.

You're no longer starting from scratch every time.

Instead, you're identifying familiar structures and applying ideas you've seen before.

Decoded tries to make those patterns easier to spot through visual explanations and guided breakdowns.

For example, the Two Pointers section shows how pointers move through an array, when they move, why they move, and which types of interview problems commonly rely on the technique.

Understanding Data Structures

Alongside problem-solving patterns, I also added short explanations for common data structures:

Arrays
Stacks
Queues
Trees
Graphs
Heaps
Hash Maps

The goal isn't to provide a deep theoretical reference.

It's simply to help answer a few practical questions:

How does this data structure behave?
When should I use it?
Why does it appear so often in coding interviews?

For example, you can visualize how array operations work and compare approaches like linear search and binary search to better understand their trade-offs.

Why I Built It

The idea behind Decoded is simple.

I wanted a resource that focused less on memorizing solutions and more on understanding how solutions are discovered.

Something that makes algorithms feel a little less intimidating and a little more intuitive.

It's not meant to replace practice.

It's meant to make the reasoning behind problems easier to see.

If you're currently learning DSA and want a more visual, step-by-step approach, you can try it here:

👉 https://www.decoded-app.com/

How I Built a Malayalam Learning App as a Tribute to My Mother Tongue

Sreya Satheesh — Tue, 12 May 2026 08:35:56 +0000

I enjoy learning languages.

Growing up in Kerala, Malayalam was always around me.

At some point, I started wondering what it would feel like to build something that helps people learn Malayalam.

That idea eventually became Aksharam — a simple Malayalam learning app designed to help beginners learn the language.

Aksharam (അക്ഷരം) means letter in Malayalam.

The goal of the app is simple: help beginners learn Malayalam step by step, from individual letters to words and sentences.

What Aksharam Includes

The app currently includes:

സ്വരാക്ഷരങ്ങൾ (Vowels)
വ്യഞ്ജനങ്ങൾ (Consonants)
ചില്ലക്ഷരങ്ങൾ (Chillu Letters)
കൂട്ടക്ഷരങ്ങൾ (Compound Letters)
സ്വരചിഹ്നങ്ങൾ (Signs & Combinations)
വാക്കുകൾ (Words)
വാക്യങ്ങൾ (Sentences)

Each lesson includes audio pronunciation support and English transliteration to make learning easier for beginners.

The app is designed primarily for people who are new to Malayalam—whether they're language enthusiasts, students, members of the Malayalam diaspora, or simply curious about learning the language.

Keeping the Learning Process Simple

While building Aksharam, I wanted the experience to feel simple, clean, and easy to follow.

Learning a language takes time. It's less about memorizing everything at once and more about becoming familiar with the language through repetition and practice.

Instead of trying to include too many features, I focused on smaller learning steps and everyday vocabulary that learners are likely to encounter early on.

The goal was to create something approachable rather than overwhelming.

Why I Built It

This project started as a way to explore language learning, but it gradually became something more personal.

Malayalam is a language I grew up hearing every day.

Building Aksharam gave me an opportunity to contribute something back to it in a small way.

It's still a work in progress, and there are plenty of things I'd like to improve.

But I'm happy to finally share it.

If you'd like to explore the language or know someone who might benefit from it, you can try Aksharam here:

https://aksharam-app.vercel.app/