How WhatsApp Handles Millions of Messages Every Day

Type "ok" into WhatsApp and hit send. By the time you've put the phone down, that word has been encrypted on your device, sent up a connection that's been open since you unlocked the screen, routed through Meta's data centres, delivered to the other person's phone, and confirmed back to you with two grey ticks. Most of the time the whole trip takes well under a second.

WhatsApp does this for more than three billion people a month. That's the number Mark Zuckerberg gave on Meta's Q1 2025 earnings call. The last daily figure Meta published was back in 2020, when it said people were sending more than 100 billion messages a day. Roughly a billion more people use the app now. Even at the 2020 rate, that's over a million messages a second, all day and all night, with much bigger spikes on nights like New Year's Eve.

So the title undersells it a bit. It's billions, not millions.

You'd expect a system like that to need a huge engineering department. It didn't. When Facebook bought WhatsApp for $19 billion in 2014, the app had around 450 million users and 32 engineers. It scaled because a small team made a few sensible decisions early and stuck to them.

This post walks through those decisions: how phones stay connected, why the servers run on Erlang, what happens when the other person is offline, what the ticks actually mean, and how groups, media and encryption work. Towards the end I look at which parts are worth borrowing if you're building a chat feature, a booking app with live updates, or anything else that has to happen in real time.

I build web applications and mobile apps with real-time features, so I deal with these problems regularly, just at a far smaller scale. WhatsApp hasn't published a full description of its current architecture. Everything here comes from its engineers' public talks, Meta's engineering blog and WhatsApp's security whitepaper, and where I'm describing a common pattern rather than a confirmed detail, I say so.

The short answer

Every phone that's online keeps a single connection open to WhatsApp's servers, and new messages get pushed down it the moment they arrive. The phone never has to keep asking whether anything's new.

The servers run on Erlang, a language Ericsson designed for telephone switches. It can run millions of tiny processes on one machine, keeps one failure from taking down everything else, and lets engineers ship new code without dropping connections. Back in 2012, WhatsApp reported more than 2 million simultaneous connections on a single server.

If the person you're messaging is offline, the encrypted message waits on the server (WhatsApp's privacy policy says for up to 30 days) and gets deleted once it's delivered. WhatsApp moves messages. It doesn't archive them.

On top of that, every chat is end-to-end encrypted with the Signal Protocol, so the servers are moving data they can't read. Photos and videos travel on a separate path from text. And the product itself was kept deliberately small for years, which may have mattered as much as any technical choice.

The numbers over the years

Here's what WhatsApp and Meta have said publicly:

Year	Milestone	Source
2009	WhatsApp founded by Jan Koum and Brian Acton	Company history
2012	2M+ concurrent TCP connections on one server	WhatsApp engineering blog / Rick Reed, Erlang Factory 2012
2014	~450M monthly users, 32 engineers, acquired by Facebook for $19B	Acquisition coverage
2014	~11,000 CPU cores, ~70M Erlang messages per second internally	Rick Reed, "That's 'Billion' with a 'B'", Erlang Factory 2014
2016	End-to-end encryption on by default for all chats	WhatsApp announcement
2020	2B monthly users; 100B+ messages per day	Meta earnings call
2021	Multi-device: up to four linked devices without the phone online	Meta engineering blog
2025	3B+ monthly users	Meta Q1 2025 earnings call

The 2014 row works out to about 14 million users per engineer. And the 2012 and 2014 figures came from a fairly small fleet of powerful machines, not tens of thousands of cheap servers. WhatsApp's habit was to get much more out of each machine before adding another one.

A crowd of people holding up their phones to film a procession. Every one of those phones holds an open connection that WhatsApp's servers have to keep alive

What happens when you send one message

Before looking at the individual pieces, it helps to follow one message from Alice to Bob. This is simplified, but the shape is right.

Alice's phone already has an open, encrypted connection to one of WhatsApp's edge servers. The security whitepaper says this client-to-server link uses the Noise Pipes protocol. When she taps send, her phone encrypts the message for Bob's devices using the Signal Protocol, so the server never sees the text. The encrypted envelope goes up the open connection with a message ID and Bob's address, in WhatsApp's own compact binary format.

The server confirms it has the message, and Alice sees one grey tick.

Next the server works out where Bob is connected. If he's online, his session lives in a process on one of the chat servers, and the envelope gets routed there and pushed down his connection. Bob didn't have to ask for it.

Bob's phone decrypts the message and sends back a delivery acknowledgement. Alice sees two grey ticks, and the server deletes its copy. When Bob opens the chat, his phone sends a read receipt (unless he's turned them off), and the ticks turn blue.

If Bob is offline, the envelope sits in an offline queue instead. His phone gets a push notification through Apple's or Google's notification service to wake it up, and delivery continues as soon as the app reconnects.

Everything below exists to make that sequence fast, cheap and reliable for three billion people.

1. Connections that stay open

Most of the web works on request and response. Your browser asks for something, the server answers, and the connection closes. A chat app built that way would have every phone asking "anything new?" every few seconds. That's polling. At WhatsApp's size it would mean billions of pointless requests a minute, nearly all of them answered with "no", and messages would still show up late.

WhatsApp does the opposite. Each connected phone opens one long-lived connection and keeps it open, and the server holds the other end. When a message comes in for you, the server writes it straight down that pipe.

That one decision gets you a lot. Delivery is instant because there's no polling interval. Each message costs very little, because a small binary frame is far lighter than a full HTTP request with headers, cookies and a fresh TLS handshake. And presence comes almost for free. If your connection is open, you're online, and things like "last seen" and "typing…" are just small events sent over the same pipe.

The cost is that the server now has to hold millions of open connections at once, and most of them are idle most of the time. Every connection uses memory, and dead ones have to be noticed and cleaned up. In the late 2000s, a server that could hold tens of thousands of open connections was doing well. The well-known "C10k problem" was about handling ten thousand.

WhatsApp needed hundreds of times that on each machine, and that's where Erlang comes in.

2. Erlang

WhatsApp's backend started out as ejabberd, an open-source chat server written in Erlang that spoke a modified version of the XMPP protocol. Over the years the team rewrote much of it and swapped XMPP's wordy XML for a compact binary format. They kept Erlang, and it carried the company a long way.

Ericsson built Erlang in the 1980s to run telephone exchanges. Those systems had to connect millions of calls, never go down, and be upgraded while running. Swap "calls" for "messages" and you've more or less described WhatsApp's requirements.

Millions of small processes

Erlang doesn't have you juggle threads. Instead you create processes, which are very light units of work managed by the Erlang virtual machine (called BEAM) rather than by the operating system. A new process takes a few kilobytes of memory, so one machine can run millions of them.

That makes a simple design possible, with one process for each connected user. The process owns that user's socket, holds their session state, and talks to other processes by passing messages. A loop like that might look roughly like this. It's a sketch to show the idea, not WhatsApp's code:

%% One of these runs for every connected phone.
session_loop(Socket, User) ->
    receive
        {deliver, Envelope} ->              % a message routed to this user
            ok = send_frame(Socket, Envelope),
            session_loop(Socket, User);
        {tcp, Socket, Frame} ->             % something the phone sent up
            handle_client_frame(User, Frame),
            session_loop(Socket, User);
        {tcp_closed, Socket} ->             % phone went away
            presence:set_offline(User)
    end.

In that model, sending a message from Alice to Bob is basically one Erlang process sending a message to another, whether they're on the same machine or spread across the cluster.

Letting things crash

Erlang processes don't share memory, so when one crashes it can't corrupt the others. They're organised into supervision trees, where a supervisor watches a group of workers and restarts any that die. The Erlang community's motto for this is "let it crash". Rather than writing defensive code for every possible error, you keep failures contained and restart cleanly.

For a messenger, that means a malformed packet or an odd bug takes down one person's session for a moment. The two million other people on the same server don't notice.

Updating code while it runs

Erlang can also swap in new code without stopping the system. WhatsApp's engineers have talked about pushing fixes to live servers without dropping the connections on them. When a restart means millions of phones all reconnecting at once, being able to avoid restarts is a big deal.

Pushing it to 2 million connections and beyond

Choosing Erlang wasn't the whole story. In his 2012 and 2014 talks at Erlang Factory, WhatsApp engineer Rick Reed described tuning the operating system (FreeBSD at the time), patching the BEAM virtual machine to cut down lock contention, splitting data up so no single node became a hotspot, and measuring everything. In January 2012 WhatsApp said it had passed 2 million concurrent connections on one server. By 2014, Reed was describing a system of about 11,000 cores passing around 70 million Erlang messages a second internally.

They chose a runtime that suited the problem, then kept pushing it, instead of throwing hardware at a poor fit.

A rack of servers with orange network cables. WhatsApp's early approach was to make each machine hold millions of connections, rather than spreading the load over endless cheap boxes

3. A post office, not a library

This one's easy to overlook, and it saves an enormous amount of work. WhatsApp doesn't keep your chat history on its servers.

The server's job is to get a message to the recipient's devices. Once delivery is confirmed, the server's copy is deleted. If the recipient is offline, WhatsApp's privacy policy says the encrypted message is kept for up to 30 days while delivery is retried, and then dropped. Your history lives on your phone and in whatever backup you've set up, not in some giant searchable archive on WhatsApp's side.

Email and Slack work differently. Their servers are the permanent record of every message ever sent, and that takes a lot of replicated storage, search indexes, retention rules and archiving.

WhatsApp's approach turns the server into a queue, and queues are much easier to scale than archives. Most messages are delivered within seconds, so at any given moment the queue only holds what's in transit or waiting for someone to come back online. Data gets written, read once and deleted, which storage systems handle very efficiently. And not keeping messages is better for users' privacy as well as cheaper to run.

In the early years, WhatsApp leaned heavily on Mnesia, Erlang's built-in distributed database, for this kind of in-memory state, with the data split across machines so no single node turned into a bottleneck.

Why messages don't get lost or doubled

Every message has a unique ID, and each step is acknowledged by the client and the server. If a connection drops halfway through, the phone reconnects and resends anything that wasn't acknowledged. Duplicates are recognised by their ID and thrown away. The technical name for this is at-least-once delivery with idempotent handling. Your message might actually be sent twice over a bad mobile connection, but you'll only ever see it once. That's a big part of why WhatsApp feels reliable on patchy networks.

4. What the ticks mean

Most people read the ticks socially, as in "they've seen it and haven't replied". Technically they're showing you the delivery protocol at work.

What you see	What it means technically
🕓 Clock	Still on your phone; the server hasn't acknowledged it yet (you might be offline)
✓ One grey tick	The server has received and stored the message
✓✓ Two grey ticks	At least one of the recipient's devices has received it and acknowledged delivery
✓✓ Two blue ticks	The recipient opened the chat and their phone sent a read receipt

In a group, you only get two grey ticks once every member has received the message, and blue ticks once everyone has read it. "Message info" shows the breakdown person by person.

There's a design idea here worth copying. The ticks show the system's real state, plainly. WhatsApp never tells you a message has arrived when it hasn't, and that honesty is part of why people trust it.

5. Groups

A message to a group of 200 people is a fan-out problem, where one message becomes 200 deliveries. The obvious approach would have the sender's phone encrypt the message 200 times and upload all of it over a mobile connection, for every single message. That falls apart quickly with large groups.

WhatsApp uses the Sender Keys scheme from the Signal Protocol instead. The first time you post in a group, your phone creates a sender key and sends it once to each member, encrypted individually. From then on, each group message is encrypted once with that sender key. Your phone uploads that one ciphertext, and the server copies it out to every member's devices.

The heavy copying happens on WhatsApp's servers, where bandwidth is cheap, and the encryption is still end to end. When someone leaves the group, the keys are rotated so they can't read anything sent afterwards.

Fan-out also explains a lot of WhatsApp's limits. Groups have a maximum size, and features for big audiences, like Channels, use a separate one-to-many broadcast design. Those limits are as much engineering decisions as product ones.

A concert crowd holding up glowing phones. Traffic spikes, like everyone messaging at midnight on New Year's Eve, are what a messaging system has to be designed for

6. Photos, videos and voice notes

A text message is a few bytes. A video can be hundreds of megabytes. If media went through the same chat servers as text, a handful of popular videos could crowd out billions of small messages.

So media goes a different way. According to WhatsApp's security whitepaper, your phone first creates a random encryption key and encrypts the file locally. It uploads the encrypted blob to WhatsApp's blob storage, which is built for large files and fast downloads. Then it sends an ordinary end-to-end encrypted chat message containing where the blob is, the key, and a hash for checking the download. The recipient's phone fetches the blob, checks the hash and decrypts it.

The chat servers only ever handle a few hundred bytes per media message, and the storage servers only ever hold files they can't read. Each side can then scale for what it's good at. The chat layer cares about connection counts and latency, and the media layer cares about bandwidth and storage.

Compression on the phone matters just as much. WhatsApp shrinks photos and videos before uploading them, unless you choose HD or send the file as a document. That saves WhatsApp bandwidth, gets the file there faster, and uses less of your data. On the cheaper phones and uneven mobile networks you find across much of India, Kashmir included, that compression is a big reason the app feels quick.

7. End-to-end encryption for billions of people

Since April 2016, every WhatsApp chat has been end-to-end encrypted by default with the Signal Protocol, which was developed by Open Whisper Systems.

Each device has its own identity keys. The public keys are registered with WhatsApp's servers, and the private keys never leave the device. Sessions can be set up even when the other person is offline, using one-time keys uploaded in advance (this is the X3DH key agreement). A store-and-forward system needs that, because the recipient often isn't around when the first message is sent.

The keys also change with every message. The Double Ratchet algorithm derives a fresh key each time, so a key stolen today can't unlock yesterday's messages, and a session recovers by itself after a compromise.

You can check all this yourself. The "security code" in a contact's info lets two people confirm they really are talking to each other. In 2023 WhatsApp started rolling out key transparency as well, which is a public, auditable directory of keys that makes it possible to detect a swapped key automatically.

It surprises people that encryption helps with scaling, but it does. Since the servers can't read message content, they don't do anything with it. There's no indexing, no scanning message bodies and no search to build. They just route sealed envelopes, and the expensive cryptography happens on three billion phones instead of in the data centre.

Linked devices

For years, WhatsApp Web was really just a mirror of your phone. If the phone's battery died, the web session stopped too, because the phone held the only keys.

In 2021 WhatsApp launched proper multi-device support, letting up to four companion devices work on their own. Meta's engineering blog explained how. Every device gets its own identity keys, and in one-to-one chats the sender uses client fan-out, encrypting the message separately for each of the recipient's devices (and the sender's own other devices) and sending it N times. Groups still use sender keys. When you link a new device, your chat history is transferred to it end to end, directly from your phone.

Syncing everything through a central server would have been far easier, but it would have broken the encryption promise. WhatsApp took the harder route, and the architecture bent around the security requirement rather than the other way round.

A brass combination padlock resting on a laptop keyboard. With end-to-end encryption, WhatsApp's servers route envelopes they cannot open

8. Staying up when things break

With this many machines, something is always broken. A disk fails, a network link goes down, a server dies, sometimes a whole hall in a data centre has a problem. The system is built on the assumption that this is normal.

Failures are kept small. Erlang processes contain problems to one user's session, and data is split up so that losing one partition affects a slice of users rather than everyone.

Phones reconnect by themselves, but with randomised delays (backoff with jitter), so a restarted server isn't hit by millions of phones in the same instant. Because every message has an ID, retrying after a failure is always safe.

Under extreme load, less important work can wait. Presence updates, "typing…" indicators and status views can be delayed or dropped before message delivery is touched.

And capacity is planned around the worst minutes, not the average ones. Midnight on New Year's Eve, big festivals and major sporting events push traffic to many times its normal level. A messaging app gets judged on those moments, so the headroom has to be there in advance.

After the acquisition, WhatsApp moved from rented bare-metal servers onto Meta's own data-centre infrastructure, but the Erlang-based core stayed.

9. Saying no

Almost every write-up of WhatsApp's architecture mentions Erlang. Fewer mention the discipline that let Erlang be enough.

For its first several years WhatsApp was famously focused. It had no ads, no games and no news feed, and for a long time it didn't have stickers either. Jan Koum kept a note from Brian Acton on his desk that read "No Ads! No Games! No Gimmicks!" Every feature you don't build is one you don't have to run servers for, put on call, migrate or security-review.

That focus is how 32 engineers kept 450 million people connected. With fewer features there was less code and fewer ways for things to fail. Encryption, compression and history storage happened on the phone, which kept the servers simple. Constant profiling meant bottlenecks turned up in measurements rather than in outages. And with few microservices and frameworks, there weren't many places for latency and bugs to hide.

Of everything in this post, that's the lesson that carries over best to businesses that will never see a billion users. Keeping things simple is a way to scale.

Colourful code on a dark monitor. Most of WhatsApp's scaling came from careful engineering decisions, not from a huge headcount

WhatsApp's architecture on one page

Problem	WhatsApp's answer	Why it works
Instant delivery to billions of phones	One persistent connection per online device	Push, not poll; tiny per-message overhead
Millions of connections per machine	Erlang/BEAM lightweight processes, heavily tuned OS and VM	One cheap process per user; failures isolated
Offline recipients	Store-and-forward queue, delete after delivery	Small, short-lived storage instead of an archive
Reliability over flaky networks	Message IDs, acknowledgements, idempotent retries	At-least-once delivery, exactly-once display
Groups	Signal Sender Keys + server-side fan-out	One encryption per message; server does the copying
Large media	Encrypted blobs on separate storage; pointer + key in chat	Heavy traffic never touches the chat path
Privacy	Signal Protocol, end-to-end by default	Servers route sealed envelopes; crypto cost is on devices
Multiple devices	Per-device keys, client fan-out	Works without the phone, without breaking encryption
Constant failures	Supervision trees, partitioning, backoff, graceful degradation	Failures stay small and recover automatically
Complexity	A deliberately narrow product	Less to build, run and secure

Blue and pink light glowing at the ends of fibre-optic strands. A message's trip from one phone to another crosses carrier networks, undersea cables and data centres in a fraction of a second

What a normal business can take from this

You're not building WhatsApp. You almost certainly don't need Erlang, a custom binary protocol or your own blob storage, and anyone proposing that for a startup's first version is selling you complexity you'll pay for later. But plenty of businesses need some of what WhatsApp does. Live order tracking, in-app chat between customers and staff, booking updates that appear without a refresh, dashboards that change as new data comes in, notifications that actually arrive. Here's how the same ideas apply at a normal size.

Push live updates instead of polling

If your app refreshes every few seconds to check for changes, it's slower and more expensive than it has to be. WebSockets and Server-Sent Events give you the same persistent-connection model in any modern stack. For a lot of businesses, a managed real-time service such as Supabase Realtime, Pusher, Ably or Firebase makes more sense than running it yourself, because it handles connections and fan-out for you. The on-demand mechanic booking app I worked on uses this for live job tracking, so customers can watch progress instead of phoning the garage to ask.

Give every action an ID

Put a unique ID on every order, payment and message, and have the server quietly ignore duplicates. Mobile connections drop requests all the time, and customers double-tap "Pay". Idempotency costs very little to build and protects you from duplicate orders and double charges.

Keep slow work off the main path

WhatsApp sends media around its chat servers, and you can do the same with uploads, report generation, image processing and emails. Put them on a background queue so the user gets an instant response while the heavy work happens behind the scenes. My guide to Next.js architecture covers how to structure that.

Tell users what's really happening

The ticks work because they're honest. Order status can work the same way: "Order received", "Being prepared", "Out for delivery". Clear, live status cuts down on support calls and anxious "where's my order?" messages more than almost anything else you could add.

Let the device do some of the work

Compress images before they're uploaded, validate forms in the browser, cache on the device. Every job the client handles well is one your servers don't have to. On Kashmir's mobile networks, that's often what separates an app that feels fast from one people give up on.

Plan for your busiest day

A Kashmir travel business has its peak season. A retailer has Eid and the wedding season. A school system has results day. Work out when your New Year's Eve is and load-test for that, not for a quiet Tuesday.

Build less, and build it well

Software with too many features, half of them unused, is expensive to run and hard to fix. WhatsApp won with a narrow product done very well. If you're deciding what to build first, my post on the signs you actually need custom software is a useful gut check, and website vs mobile app can help you pick the right first platform.

A small team working together on laptops around a wooden table. WhatsApp reached 450 million users with 32 engineers by keeping its product narrow and its systems simple

Building on WhatsApp itself

There's also a more direct way to benefit from all of this, which is to build on top of WhatsApp. In India, WhatsApp is usually where your customers already are, so for a lot of businesses it's the best support and sales channel they have.

The WhatsApp Business Platform (the Cloud API) lets your own systems send and receive WhatsApp messages. Set up properly, your website or software can send order confirmations, booking reminders and delivery updates automatically, to the app your customers actually check. An AI assistant can answer routine questions around the clock, like prices, availability, opening hours and order status, and hand the harder conversations to a person along with the context. Leads from WhatsApp chats can go straight into your CRM or spreadsheet instead of getting lost on someone's personal phone. And clinics, salons, workshops and tutors can send reminders that cut down on no-shows.

There are two things to be careful about. Meta has rules on message templates, opt-in consent and per-conversation pricing, and the integration has to be designed around them. An AI assistant on WhatsApp also needs guardrails so it never promises a price or delivery date your business can't honour. I've written about doing that properly in my guides to AI chatbot development and custom AI automation.

A lot of my AI & automation work is exactly this: connecting WhatsApp to the systems a business already runs, so messages turn into orders, bookings and follow-ups without anyone copying details across by hand.

A team gathered around a monitor planning together. The right architecture for your product starts with an honest conversation about what it actually needs to do

How I build real-time features for clients

Most of my clients don't need WhatsApp's scale. They need its reliability, at a price that makes sense for a growing business.

That usually starts with picking the simplest architecture that will hold up as you grow. A managed real-time service and a well-designed database will take most businesses a very long way. I'd much rather hand you something boring that works than something clever that breaks at 3 a.m.

I design for bad networks from the start. That means retries, idempotency, offline states and clear status messages, tested on real mid-range Android phones over mobile data and not just on office Wi-Fi.

I build in-app chat, live tracking and notifications into web applications and Android and iOS apps. The live job tracking in the mechanic booking platform and the patient experience in the healthcare app are two examples. I also connect those features to the rest of the business through custom software for inventory, bookings, dispatch and billing, so a real-time event actually triggers real work. The inventory management platform shows that operational side.

Security is built in by default, with encrypted connections, sensible access control, and no sensitive data kept anywhere it doesn't need to be. It's the same instinct that led WhatsApp to delete messages once they're delivered.

I've been building software for businesses in Kashmir and beyond since 2018. You work with one senior developer who designs, builds and supports the whole thing. You can see more in my case studies and read what clients say.

Frequently asked questions

How many messages does WhatsApp handle per day? Meta's last official figure, from 2020, was more than 100 billion messages a day. WhatsApp has grown from about 2 billion monthly users then to more than 3 billion (as of 2025), so the real number is probably higher now. Meta just hasn't published an updated one.

What programming language does WhatsApp use on its servers? Mostly Erlang, running on the BEAM virtual machine. The backend started from ejabberd, an open-source Erlang chat server, and has been heavily modified since. Erlang fits messaging well because it can run millions of lightweight processes on one machine, keeps failures isolated, and lets engineers update code without downtime. The mobile apps are native to each platform.

How did WhatsApp scale with so few engineers? It kept the product narrow, picked a runtime (Erlang) that suited the problem, moved work like encryption and compression onto the phone, didn't store message history on its servers, and measured and tuned constantly. In 2014, 32 engineers supported about 450 million users.

Does WhatsApp store my messages on its servers? Not once they're delivered. Messages are only held, encrypted, until they reach the recipient. If the recipient is offline, WhatsApp keeps the encrypted message for up to 30 days while it tries to deliver it, then deletes it. Your chat history lives on your devices and in any backup you choose to make.

How does WhatsApp deliver messages so fast? Every online phone keeps a connection open to WhatsApp's servers, so messages are pushed immediately instead of waiting for the phone to check. The protocol is compact and binary, the servers only route small encrypted envelopes, and media goes a separate way so it never slows text down.

What do the WhatsApp ticks mean technically? One grey tick means WhatsApp's server has your message. Two grey ticks mean the recipient's device has received it. Two blue ticks mean the recipient opened the chat and their phone sent a read receipt. A clock means the message hasn't left your phone yet.

Can WhatsApp read my messages? Not the contents of your chats. Messages are end-to-end encrypted with the Signal Protocol and the private keys stay on your devices, so WhatsApp's servers only ever see encrypted data. WhatsApp does process some metadata to run the service, which its privacy policy describes.

How does WhatsApp handle group messages? It uses Sender Keys from the Signal Protocol. Your phone shares a sender key with each group member once, and after that encrypts each group message a single time. The server then copies that one encrypted message to every member's devices.

How do WhatsApp Web and linked devices work without the phone? Since 2021, each linked device has had its own encryption keys. The sender encrypts a separate copy of each message for every one of the recipient's devices (and their own other devices), so linked devices can send and receive even when the phone is off.

Can I build a chat app like WhatsApp? You can build chat or other real-time features on the same principles, meaning persistent connections, acknowledgements, idempotent delivery, push notifications and encryption, using tools like WebSockets and managed real-time services. You don't need WhatsApp's custom infrastructure unless you're operating at a very unusual scale. Getting reliability, security and the user experience right from the start matters much more.

How much does it cost to build a real-time chat or tracking feature? That depends on scope. Adding one-to-one chat to an existing app is a very different job from a full messaging product with groups, media and encryption. The quickest way to a realistic figure is to tell me what you need. I'll give you an honest estimate, and I'll say so if something simpler would do. Request a quote here.

Can you connect my business to WhatsApp? Yes. I integrate the WhatsApp Business Platform with websites, booking systems, CRMs and custom software for automated confirmations, reminders, lead capture and AI-assisted replies, all built around Meta's template and consent rules. Have a look at my AI & Automation service or get in touch.

If you're building something real-time

None of WhatsApp's ideas need three billion users to be useful. Live order tracking, in-app chat, instant notifications or your own business connected to WhatsApp all depend on the same basics, and getting them right is what makes customers trust an app instead of giving up on it.

If you're planning something like this, tell me what you're building. I'll tell you straight what the simplest architecture that will hold up looks like, roughly what it'll cost, and what you can safely leave out. You can also go straight to a project quote, or look through my web, mobile and AI & automation services.