Scaling BookMySMS to 10,000 SMS/second at 99.9% uptime

The problem: bulk messaging is easy at 100 SMS/sec, brutal at 10,000

Anyone can send a hundred SMS a second. Get to 10,000 and the entire system changes shape. Carrier throttling that never mattered at low volume becomes your bottleneck. TRAI DLT rules that were background noise become gate-keepers on every request. WhatsApp Business API rate limits force you into per-phone-number budgeting. And when one of your seven carriers has a bad hour, "just retry" isn't a strategy — that's how you send the same OTP six times to one user.

BookMySMS started as Decipher's internal messaging tool for our own client projects. When traffic crossed a certain threshold, we spun it out as a standalone product. Today it powers messaging for banks, insurance companies, EdTech platforms, e-commerce brands, and government projects — sending millions of messages daily across SMS, WhatsApp Business API, RCS, and Voice.

This case study walks through the architectural decisions that got us to sustained 10,000 SMS/second throughput with 99.9% uptime SLA — and what breaks when you scale a messaging platform.

The architecture

DLT compliance as an API gate

Every SMS in India must resolve to a TRAI-registered DLT template. Get it wrong and the carrier rejects the message — you're charged for the send anyway, and worse, repeated rejections harm your sender reputation across all operators.

Our approach: enforce DLT at the API layer, not at the send layer. When a client submits a message, we resolve:

• Entity ID — the registered business entity
• Template ID — the specific message template
• Header (Sender ID) — the approved 6-character sender
• Content match — the actual content matches the registered template (with variable slots resolved)

If any of these fail, the API returns a 400 with a specific error code (e.g., DLT_TEMPLATE_NOT_FOUND, DLT_CONTENT_MISMATCH). The message never enters the queue. This alone cut our carrier-side rejections by ~85% when we moved from post-hoc DLT checking to pre-send validation.

Multi-carrier failover: the health scoring system

We're integrated with 7+ Indian SMS carriers plus WhatsApp Business API, Twilio for international, and multiple Voice providers. Each has different pricing, throughput limits, operator coverage, and — critically — different failure modes.

The routing engine maintains a health score for each carrier, updated every 30 seconds. Score inputs:

• Delivery rate — successful DLRs / total sent, over rolling 5-min window
• API latency — p95 response time from the carrier's API
• Error rate — HTTP 5xx or SMPP NACKs
• Throughput budget — how much of the carrier's contractual rate limit we've used this minute
• Operator-specific delivery — Jio delivery via Carrier A might be 98%, but Vi delivery might be 87% — routing accounts for this

When a carrier's score drops below threshold, new messages route to alternatives within one second. When the carrier recovers, we ramp traffic back gradually (not all at once — that just triggers rate limits again).

Real incident: the 3 AM carrier outage

In early 2024, our largest SMS carrier had a 45-minute regional outage during OTP peak hours (3 AM IST — banking systems doing overnight batch operations). Their API returned 200 OK for accepted messages but silently dropped 60% of deliveries.

Traditional "retry on failure" would have doubled our send volume trying to recover. Our health scoring caught the drop within 90 seconds (delivery rate crashed from 97% to 38%), reweighted routing to secondary carriers, and drained the queue through them at 70% of original throughput.

The client's monitoring didn't page anyone. They noticed the incident on our weekly delivery report the following Monday. That's what failover done right looks like.

WhatsApp Business API at scale

WhatsApp is not SMS. Different rules, different constraints:

• Session windows — you can only message a user within 24 hours of their last message to you, unless you use approved templates
• Rate limits per phone number — Meta assigns tiers (250, 1K, 10K, 100K conversations/day) based on your quality rating
• Template approval — every marketing message needs a pre-approved template, and Meta rejects for arbitrary reasons
• Quality rating — too many blocks/reports and Meta downgrades your tier, capping your throughput

BookMySMS abstracts all of this. Client submits a WhatsApp send via the same unified API used for SMS. Internally:

1. Template resolver checks if a matching approved template exists
2. Session manager checks if the recipient is inside a 24-hour session window (uses inbound message tracking)
3. Rate limiter checks per-number budget for the day (based on our current Meta tier)
4. Quality guard applies rules to prevent quality-damaging patterns (excessive frequency, opted-out numbers)
5. Message goes through — or the API returns a specific error telling the client what to fix

The results, in numbers

What managed operations means for a system like this

Building this system was 20% of the work. Running it is the other 80%. Every day, someone at Decipher is:

• Reviewing carrier health trends and adjusting routing weights
• Getting new client DLT templates registered and validated
• Monitoring WhatsApp quality rating and preventing tier downgrades
• Auditing DLR anomalies (why did message X take 4 hours to deliver?)
• Managing infrastructure — auto-scaling queues, ClickHouse compaction, log retention
• Responding to client integration issues at 2 AM when their OTP flow breaks in production
• Negotiating carrier contracts and adding new providers

This is what managed application operations means in practice — it's not just monitoring a dashboard. It's owning the SLA end-to-end while the client team focuses on their actual business.

What we'd do differently

1. Start with ClickHouse from day one. We spent 18 months on PostgreSQL for DLR storage before hitting a wall. Migration to ClickHouse took 4 weeks and immediately cut query times from minutes to milliseconds. Should have gone columnar from the beginning at this write volume.
2. Build the DLT compliance layer before onboarding the first client. We built it retrofit after too many carrier rejections. Every subsequent SaaS messaging build we've done starts with DLT enforcement in Week 1.
3. Invest in observability sooner. Our current combination (Prometheus + Grafana + Loki + ClickHouse for business metrics) took 18 months of iteration. If we did it again, we'd stand up the full observability stack in Week 1, not Month 6.

Can we build something similar for you?

Not everyone needs 10,000 SMS/second. But the same architectural patterns — pre-validation gates, health-based routing, unified API over messy underlying providers, columnar analytics — apply whenever you're building a platform that sits between real users and multiple upstream providers. Payment gateways, video streaming, IoT ingestion, ad-tech bidding — different domain, same shape of problem.

If you're building or scaling a system like this and want to skip the 18-month learning curve, book a call. We'll tell you honestly whether the problem is worth building from scratch or whether an existing platform will get you 80% there.