# Design an SMS platform like Twilio: system design interview question

> An SMS platform must control carrier load, track uncertain delivery, and charge each tenant correctly.

Source: https://sysround.com/questions/design-sms-platform-like-twilio
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a programmable SMS platform for businesses. Tenants use an API to send texts and receive texts through telecommunications carriers. The platform also reports delivery status and charges each tenant for use."

## What to clarify first

- Traffic
- Read and write mix
- Segments and carrier limits
- Latency
- Acceptance and consistency
- Delivery and retries
- Tenant charges
- Inbound messages and tenant webhooks
- Retention
- Scope boundaries

## Scope of a strong answer

Core requirements:

- Accept outbound SMS requests and report message status
- Receive inbound SMS and send events to tenant webhooks
- Apply carrier limits and retry rules across tenants
- Record billable use and produce monthly tenant invoices

Usually out of scope:

- Number purchase and porting
- Carrier contracts and sender registration
- MMS and campaign tools
- Tax calculation and payment collection

## What interviewers probe

### Carrier capacity and tenant delays

Carrier limits count SMS segments, not API calls. Shared routes must handle tenant bursts without excessive delay or expired sends.

### Uncertain send results

A carrier can accept a segment before the connection fails. A resend can create a second text and another carrier charge.

### Message status and tenant events

Receipts can arrive before send replies or after newer states. Inbound duplicates and failed tenant webhooks create separate delivery obligations.

### Usage and tenant charges

Carrier acceptance can remain unknown beyond invoice finalization. Late evidence and repeated events must not create missed or duplicate tenant charges.

## Common mistakes

- Counts API requests instead of SMS segments when checking carrier limits.
- Treats a carrier timeout as proof that no text left the platform.
- Treats carrier acceptance as proof of handset delivery.
- Bills every retry or receipt as new use.
- Lets one tenant delay every other tenant on a shared route.
- Charges unresolved attempts or changes finalized invoices after late evidence.

## The bar by level

- **Senior:** Separates API retries from carrier retries. Enforces segment limits and tenant fairness. Handles uncertain outcomes without blind resend. Prevents duplicate charges and recovers failed tenant webhooks. Applies the stated unresolved-attempt and late-charge policies.
- **Staff+:** Explains route ownership during failures and regional isolation. Quantifies costs from uncertain sends and duplicate carrier charges. Preserves evidence across content deletion and invoice finalization. Uses backlog age and route capacity to justify overload and recovery rules.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=programmable-sms


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.