The hardest part of building on WhatsApp isn't WhatsApp. It's that you're building an enterprise product line on top of an API you don't own, can't see the roadmap for, and which offers you no SLA — while your own customers expect one from you. Every architectural decision downstream of that is really a decision about how to stay reliable on top of something you don't control.
In 2021 I left the web push team and started two of those product lines from zero: WhatsApp and SMS. Today WhatsApp moves roughly 185 million messages a month and SMS around 220 million including transactional traffic. This is what it took to get from the first message to that.
Day zero: two products that started as siblings
WhatsApp and SMS didn't begin as one system, and they didn't begin as two unrelated ones either. They started as siblings — separate projects sharing a similar architecture, because at the beginning the problems rhymed: take a customer's intent, resolve it against an audience, respect a provider's rate limits, send, and track what came back.
Then they diverged, and the divergence was the interesting part. The programming languages drifted apart. The messages-per-second limits were shaped by completely different upstreams. The architectural pressures stopped rhyming. What looked like one problem at the start turned out to be two problems that happened to share a silhouette.
The team shape tracked that arc. At the start it was one team and I was the team lead. In 2024 the two products split into two separate product teams, and I became the umbrella tech lead across both — close enough to keep them coherent, separate enough to let each follow its own constraints.
BSP and API realities: the part nobody writes about
WhatsApp Business API in its early on-premise era was an operations problem before it was a product problem. You were running someone else's stack to reach their network, and everything about your reliability was downstream of decisions made outside your building.
The migration to the Cloud API was the sharpest edge of that period. We moved every customer across, and it was a painful process — the kind where the average case is fine and the tail is brutal. The worst cases were tenants who had lost their phone number, or had no contacts left to re-establish identity with. Migrating a healthy account is mechanical; migrating an account that has lost the thing that proves it's an account is a negotiation with edge cases. But all of them made it across.
I'll keep the platform specifics vague on purpose — some of this lives under partner and security constraints — but the shape is the point: when your foundation is someone else's containerized stack and then someone else's cloud, "migration" is not a project you run once. It's a posture you keep.
The template and session model: designing around a state machine
WhatsApp doesn't let you send whatever you want whenever you want. There's a conversation state machine underneath it — session windows, approved templates — and your infrastructure has to model that state faithfully or you send things the platform rejects.
We track conversation state per user in DynamoDB, with a Redis caching layer in front of it and a 90-day TTL to keep the state store honest about what's still relevant. The other half of the model is templates, and templates come with an approval process you don't control. The rejections clustered where you'd expect once you'd seen enough of them: content that wasn't appropriate for the channel, promotional material dressed as something else, and templates whose structure simply didn't meet the platform's rules. Knowing the rejection patterns is its own quiet expertise — it's the difference between a template that ships today and one that bounces for a week.
Quality ratings: when the platform grades your customers
The unusual part of running WhatsApp at enterprise scale is that Meta grades your customers' behavior, and their grade constrains your throughput. A customer's number can have its quality dinged and its rate tier dropped for reasons that originate in their messaging habits, not your infrastructure — and you inherit the consequences. So a meaningful amount of the platform's job is protecting customers from their own worst campaigns, and protecting every other customer from the one having a bad day.
The platform–product tension
Building on an API with no SLA to you, under customers who expect an SLA from you, is a permanent tension rather than a problem you solve once. The platform ships new features that arrive buggy. A real slice of the work is running the support and resolution loop through the platform's own channels to get those issues fixed. And sometimes you're the surface through which the platform quietly pilots its own features to tenants — you become the MVP path for something you didn't design. There are many examples; most of them I can't detail for security reasons. The generalizable lesson is the one worth keeping: when you build on a platform, part of your architecture is organizational, not technical. You're building the process that absorbs the platform's surprises so your customers never have to.
Today's architecture
The WhatsApp pipeline today is a fairly long chain, and each link earns its place: a campaign is prepared, resolved against user-based queries and reads, run through content replacement, then queued according to the messages-per-second limits that apply. From there a realtime pool manager drives the actual sending, every message writes a log event, callbacks are tracked, and reply flows feed back in — a reply can trigger its own downstream events, and for API-based customers the whole thing closes with a callback loop back to the tenant.
SMS follows a similar spine but is, if anything, harder to manage. Its MPS, segment, and part pools are fully dynamic and shaped per provider and per sender, which makes the management surface considerably more complex than WhatsApp's. And notably, none of this shares a backbone with the web push system I'd worked on before — these were built as their own thing, with their own constraints, from zero.
What I'd do differently
If I built these again, the changes I'd make aren't really about any single pipeline. I'd invest earlier and harder in the parts that don't show up in a demo: monitoring and alerting, and cleaner, more systematic deployment and development flows. I'd carry fewer microservices — every service is a promise you have to keep. And I'd push the scaling flows up to the organizational level so that all the messaging products stay consistent with each other, instead of each one solving the same problem in a slightly different dialect. The infrastructure was never the hard part in the end. Keeping several products coherent, on top of platforms that don't hold still, was.
Salimcan Venedik is a Staff Software Engineer and Technical Lead at Insider, where he works on messaging infrastructure and AI product engineering. — About / Contact