SysPad › Lessons › messaging lessons › Twilio SMS

How Twilio SMS works

Programmable SMS. The bottleneck is carrier-side: ~1 msg/s per long-code number, ~100/s per short code - throughput is bought by adding senders, and at ~$0.008 per message, scale is real money.

The API returns 200 OK in a tenth of a second, and your 10,000 texts will take three hours to arrive. Welcome to SMS, where the bottleneck is not the API you called but the carrier network behind it, which meters each ordinary phone number to roughly one message per second.

What you will learn

Why is SMS throughput bought with phone numbers, not servers?
What did that 200 OK actually confirm?
When does a short code earn its ~$1,000/month?
Why is SMS the notification channel of last resort on cost?

The carrier is the bottleneck

US carriers meter A2P traffic per sender: an ordinary long code number sends about 1 message/second; a short code (the 5-6 digit kind) does ~100/s. Twilio queues what you submit and drains it at the senders' combined rate. Scaling SMS means adding senders to a Messaging Service pool.

200 OK means "queued"

The synchronous API call confirms Twilio ACCEPTED the message. Delivery happens later and is reported by status callbacks (webhooks: sent, delivered, failed). Production systems treat SMS like a queue: submit, then reconcile on callbacks, never assume.

⚓ This is why the SysPad node is an async boundary: your request path ends at the accept, exactly like SQS or SES.

The most expensive channel per byte

US SMS runs about $0.008 per segment (and long messages split into multiple billable segments). A million texts is ~$8,000; the same million as push notifications is ~$0. Short codes add a ~$1,000+/month lease, paid for by campaigns where drain time matters.

What is A2P 10DLC and why did my throughput change after registration?

US carriers require business (application-to-person) traffic on regular numbers to be registered: your brand and campaign get vetted, and the carrier assigns a throughput tier. Unregistered traffic gets filtered or heavily throttled. It is compliance plumbing, and it is also literally where your messages-per-second number comes from.

Flashcards

Ops pages you: "SMS blast started 40 minutes ago, only a third delivered, Twilio shows no errors." What is the non-bug explanation?: Carrier-rate drain: N messages over ~1/s per number in the pool is just arithmetic. The fix is capacity planning (more senders or a short code), not debugging.
Login OTPs became slow every Friday at 5pm, exactly when marketing sends its weekly blast. What is the architectural mistake?: OTPs and campaigns share a sender pool, so time-critical messages queue behind bulk. Give transactional SMS its own dedicated sender(s)/messaging service.
PM wants order-status updates via SMS "since we already have Twilio." At 500k orders a month, what do you put on the table?: ~$4,000/month for texts that push notifications deliver for ~free to app users. SMS for the no-app fallback only is the usual compromise.

Sources

Open the SysPad canvas · Official Twilio SMS documentation