Twilio API Architecture Documentation

API Product Lines, Design Patterns, and Backend Infrastructure

← Back to Study Guide

Quick Navigation

Twilio API Product Overview

Twilio's Core Value Proposition: Abstract the complexity of global telecommunications infrastructure behind simple, RESTful APIs that developers can integrate in minutes.

API Product Lines

Product Purpose Traffic Pattern Latency Sensitivity
Programmable Messaging SMS, MMS, WhatsApp, RCS Async (store-and-forward) Low (seconds OK)
Programmable Voice PSTN calls, SIP, WebRTC Real-time (connection-based) Critical (<150ms)
Programmable Video Video rooms, recordings Real-time (streaming) Critical (<150ms)
Twilio Verify OTP, 2FA, fraud prevention Sync request-response Medium (<500ms)
Lookup Phone number intelligence Sync request-response Medium (<500ms)
Flex Contact center platform Mixed (real-time + async) High (<200ms)
Segment Customer data platform Async (event streaming) Low (eventual OK)
SendGrid Email delivery Async (batch) Low (minutes OK)

Architecture Tiers

┌─────────────────────────────────────────────────────────────────────────────────────┐ │ GLOBAL TIER │ │ Services that must be available everywhere, low latency from any location │ │ │ │ • API Gateway / Cell Router (Lambda@Edge) │ │ • Identity & Authentication (DynamoDB Global Tables) │ │ • Customer → Cell Routing (DynamoDB Global Tables + Redis) │ │ • DNS (Route 53 with latency-based routing) │ │ • CDN (CloudFront for static assets, TwiML bins) │ └─────────────────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────────────────┐ │ REGIONAL TIER │ │ Services deployed per region, may have primary/secondary │ │ │ │ • Super Network (carrier connections in each region) │ │ • Media Servers (voice/video processing) │ │ • Message Queues (Kafka, regional clusters) │ │ • Lookup/Intelligence Services │ └─────────────────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────────────────┐ │ CELL TIER │ │ Customer-specific isolation, product-agnostic cells │ │ │ │ • Message Processing (per-customer) │ │ • Call State Management │ │ • Customer Data Storage (Aurora, DynamoDB) │ │ • Webhook Delivery │ │ • Usage Metering │ └─────────────────────────────────────────────────────────────────────────────────────┘

Twilio API Conventions

Base URL Structure

https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json

Components:
├── api.twilio.com          → Base domain
├── 2010-04-01              → API version (date-based)
├── Accounts/{AccountSid}   → Account scoping
├── Messages                → Resource (plural noun)
└── .json                   → Response format

Authentication

# HTTP Basic Auth with Account SID and Auth Token
curl -X POST https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json \
  -u "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_auth_token"

# Alternative: API Keys (Account SID + API Key SID + API Key Secret)
curl -X POST https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json \
  -u "SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_api_key_secret"

# API Keys provide:
# - Granular permissions (can be scoped)
# - Revocable without changing Auth Token
# - Multiple keys per account

Resource Identifiers (SIDs)

Prefix Resource Type Example
AC Account ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SM SMS Message SMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
MM MMS Message MMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
CA Call CAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
PN Phone Number PNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
RE Recording REXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SK API Key SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VE Verify Service VAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Interview Insight: SID prefixes enable quick identification of resource types in logs, debugging, and support. A 34-character SID with 2-char prefix leaves 32 chars of uniqueness—likely a UUID variant.

Request/Response Format

# Request: Form-encoded (traditional) or JSON
POST /2010-04-01/Accounts/AC.../Messages.json
Content-Type: application/x-www-form-urlencoded

To=+15551234567&From=+15559876543&Body=Hello%20World

# Response: JSON (note PascalCase for legacy API)
{
  "sid": "SM1234567890abcdef1234567890abcdef",
  "account_sid": "AC1234567890abcdef1234567890abcdef",
  "to": "+15551234567",
  "from": "+15559876543",
  "body": "Hello World",
  "status": "queued",
  "direction": "outbound-api",
  "date_created": "Wed, 15 Jan 2024 10:30:00 +0000",
  "date_updated": "Wed, 15 Jan 2024 10:30:00 +0000",
  "date_sent": null,
  "uri": "/2010-04-01/Accounts/AC.../Messages/SM....json",
  "price": null,
  "price_unit": "USD"
}

Pagination

# Request with pagination
GET /2010-04-01/Accounts/AC.../Messages.json?PageSize=50

# Response includes navigation URIs
{
  "messages": [...],
  "first_page_uri": "/2010-04-01/Accounts/AC.../Messages.json?PageSize=50",
  "next_page_uri": "/2010-04-01/Accounts/AC.../Messages.json?PageSize=50&PageToken=PA123",
  "previous_page_uri": null,
  "page": 0,
  "page_size": 50
}

# Note: Twilio uses keyset/cursor pagination (PageToken), not offset
# This is important for large datasets that change frequently

Webhook Pattern

# When creating a message, specify callback URL
POST /2010-04-01/Accounts/AC.../Messages.json
To=+15551234567
From=+15559876543
Body=Hello
StatusCallback=https://your-app.com/webhooks/message-status

# Twilio POSTs status updates to your webhook
POST https://your-app.com/webhooks/message-status
Content-Type: application/x-www-form-urlencoded

MessageSid=SM123...
MessageStatus=delivered
To=+15551234567
From=+15559876543
AccountSid=AC123...

# Your server must respond 2xx to acknowledge
# Twilio retries on failure (exponential backoff)

Programmable Messaging APIs

Traffic Pattern: Asynchronous, store-and-forward. Messages are queued, processed, and delivered with status callbacks. Latency tolerance is high (seconds to minutes acceptable).

API Endpoints

Messages Resource ASYNC

# Create (send) a message
POST /2010-04-01/Accounts/{AccountSid}/Messages.json

# Get message details
GET /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json

# List messages
GET /2010-04-01/Accounts/{AccountSid}/Messages.json

# Update message (redact, cancel)
POST /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json

# Delete message
DELETE /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json

Messaging Services ASYNC

Higher-level abstraction that manages sender selection, compliance, and scaling.

# Create messaging service
POST /v1/Services

# Add phone numbers to service
POST /v1/Services/{ServiceSid}/PhoneNumbers

# Send via service (auto-selects best sender)
POST /v1/Services/{ServiceSid}/Messages

Message Lifecycle & Status

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ accepted │───►│ queued │───►│ sending │───►│ sent │───►│delivered │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ failed │ │ canceled │ │ failed │ │undelivered│ │ read │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ (WhatsApp) Each transition triggers StatusCallback webhook if configured

Backend Infrastructure (Inferred)

┌─────────────────────────────────────────────────────────────────────────────────────┐ │ MESSAGING ARCHITECTURE │ │ │ │ ┌─────────┐ ┌──────────────┐ ┌──────────────┐ ┌─────────────────────┐ │ │ │ API │────►│ Cell Router │────►│ Customer │────►│ Message Queue │ │ │ │ Gateway │ │ (by account) │ │ Cell │ │ (Kafka/SQS) │ │ │ └─────────┘ └──────────────┘ └──────────────┘ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ SUPER NETWORK (Global) │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ │ │ US Carriers│ │ EU Carriers│ │APAC Carriers│ │LATAM Carriers│ │ │ │ │ │ AT&T, T-Mo │ │Vodafone,O2 │ │ Singtel... │ │ Claro... │ │ │ │ │ └────────────┘ └────────────┘ └────────────┘ └────────────┘ │ │ │ │ │ │ │ │ 4,800+ carrier connections | SMPP/SMPP over TLS | Intelligent routing │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ Infrastructure Characteristics: │ │ • Cells: Product-agnostic, customer-isolated │ │ • Queue: Per-cell Kafka topics for message processing │ │ • Super Network: SHARED global infrastructure (not per-cell) │ │ • Delivery: Async with retry, DLQ for failures │ │ │ └─────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Cell-Based Regional Queue Global Super Network

Cell Architecture Fit: Messaging is an excellent fit for cells. Each customer's messages are processed in their cell, providing isolation. The Super Network is shared globally—carrier connections are expensive and don't need per-customer isolation. Message queues can be regional Kafka topics partitioned by cell.

Programmable Voice APIs

Traffic Pattern: Real-time, connection-based. Voice requires sub-150ms latency for natural conversation. Media processing is regional; signaling can be more distributed.

API Endpoints

Calls Resource REAL-TIME

# Initiate outbound call
POST /2010-04-01/Accounts/{AccountSid}/Calls.json
To=+15551234567
From=+15559876543
Url=https://your-app.com/twiml/answer  # TwiML instructions

# Get call details
GET /2010-04-01/Accounts/{AccountSid}/Calls/{Sid}.json

# Modify in-progress call
POST /2010-04-01/Accounts/{AccountSid}/Calls/{Sid}.json
Status=completed  # Hang up

# List calls
GET /2010-04-01/Accounts/{AccountSid}/Calls.json

Recordings ASYNC

# List recordings for a call
GET /2010-04-01/Accounts/{AccountSid}/Calls/{CallSid}/Recordings.json

# Get recording audio
GET /2010-04-01/Accounts/{AccountSid}/Recordings/{Sid}.mp3

# Delete recording
DELETE /2010-04-01/Accounts/{AccountSid}/Recordings/{Sid}.json

Conferences REAL-TIME

# List conferences
GET /2010-04-01/Accounts/{AccountSid}/Conferences.json

# Get conference details
GET /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}.json

# List participants
GET /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}/Participants.json

# Kick participant
DELETE /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}/Participants/{CallSid}.json

TwiML (Twilio Markup Language)

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <!-- Text-to-speech -->
    <Say voice="Polly.Amy" language="en-GB">Welcome to Twilio!</Say>

    <!-- Gather DTMF or speech input -->
    <Gather input="dtmf speech" timeout="5" numDigits="1" action="/handle-input">
        <Say>Press 1 for sales, 2 for support, or say your request.</Say>
    </Gather>

    <!-- Connect to another number -->
    <Dial callerId="+15559876543" timeout="30">
        <Number>+15551234567</Number>
    </Dial>

    <!-- Play audio file -->
    <Play>https://example.com/hold-music.mp3</Play>

    <!-- Record the call -->
    <Record maxLength="300" transcribe="true" transcribeCallback="/transcription" />

    <!-- Conference call -->
    <Dial>
        <Conference waitUrl="/hold-music" startConferenceOnEnter="true">
            RoomName123
        </Conference>
    </Dial>
</Response>

Call Flow Architecture

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ VOICE ARCHITECTURE │ │ │ │ INBOUND CALL: │ │ ┌────────┐ ┌─────────┐ ┌─────────────┐ ┌───────────┐ ┌───────────────┐ │ │ │ PSTN/ │───►│ Super │───►│ Regional │───►│ Customer │───►│ Customer │ │ │ │ Carrier│ │ Network │ │ SIP Gateway │ │ Cell │ │ Webhook │ │ │ └────────┘ └─────────┘ └─────────────┘ └───────────┘ │ (TwiML fetch) │ │ │ │ └───────┬───────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────┐ ┌───────────────┐ │ │ │ Media Server│◄───────────────────│ TwiML Parser │ │ │ │ (Regional) │ Instructions │ & Executor │ │ │ │ │ └───────────────┘ │ │ │ - RTP/SRTP │ │ │ │ - Mixing │ │ │ │ - Recording │ │ │ │ - TTS/STT │ │ │ └─────────────┘ │ │ │ │ OUTBOUND CALL: │ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ ┌─────────┐ ┌────────┐ │ │ │ API Call │───►│ Customer │───►│ Regional │───►│ Super │───►│ PSTN/ │ │ │ │ POST/Calls│ │ Cell │ │ SIP Gateway │ │ Network │ │ Carrier│ │ │ └───────────┘ └───────────┘ └─────────────┘ └─────────┘ └────────┘ │ │ │ │ Key Components: │ │ • Super Network: PSTN interconnects (regional, near carriers) │ │ • Media Servers: Audio processing (MUST be regional for latency) │ │ • SIP Gateways: Protocol translation (regional) │ │ • Call State: Cell-local (ephemeral during call) │ │ • Recordings: S3 (regional, replicated to customer's region) │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Regional Media Cell Signaling Global Routing

Cell Architecture Considerations: Voice is tricky for cells. Call signaling (setup, teardown, TwiML) can be cell-based, but media processing MUST be regional for latency. A US-to-UK call might have signaling in the customer's US cell but media servers in both US and UK regions. Call state is ephemeral—stored in the cell during the call, then persisted to the database after completion.

Programmable Video APIs

Traffic Pattern: Real-time streaming. Even more latency-sensitive than voice due to visual synchronization needs. WebRTC-based with SFU (Selective Forwarding Unit) architecture.

API Endpoints

Rooms REAL-TIME

# Create a room
POST /v1/Rooms
UniqueName=DailyStandup
Type=group  # or peer-to-peer, group-small

# Get room details
GET /v1/Rooms/{Sid}

# Complete a room (end the meeting)
POST /v1/Rooms/{Sid}
Status=completed

# List participants in room
GET /v1/Rooms/{RoomSid}/Participants

Recordings & Compositions ASYNC

# List recordings
GET /v1/Rooms/{RoomSid}/Recordings

# Create composition (combine recordings)
POST /v1/Compositions
RoomSid=RM123...
AudioSources=*
VideoLayout={"grid":{"video_sources":["*"]}}

# Get composition status
GET /v1/Compositions/{Sid}

Room Types & Architecture

Room Type Max Participants Architecture Use Case
Peer-to-Peer (P2P) ~4 Direct WebRTC between clients 1:1 calls, small meetings
Group Small ~6 SFU with optimization Small team meetings
Group 50 SFU (Selective Forwarding) Large meetings, webinars
┌──────────────────────────────────────────────────────────────────────────────────────┐ │ VIDEO ROOM ARCHITECTURE (SFU) │ │ │ │ ┌─────────────────────────┐ │ │ │ SFU Media Server │ │ │ │ (Regional) │ │ │ │ │ │ │ ┌──────────┐ │ ┌─────────────────┐ │ ┌──────────┐ │ │ │ Client A │◄────────┼──┤ Receive tracks │ │─────────►│ Client B │ │ │ │ (sends │ │ │ from all others │ │ │ (receives│ │ │ │ video) │────────►│ └─────────────────┘ │◄─────────│ all) │ │ │ └──────────┘ │ │ └──────────┘ │ │ │ ┌─────────────────┐ │ │ │ │ │ Forward to each │ │ │ │ ┌──────────┐ │ │ subscriber │ │ ┌──────────┐ │ │ │ Client C │◄────────┼──┤ (no transcoding)│ │─────────►│ Client D │ │ │ └──────────┘ │ └─────────────────┘ │ └──────────┘ │ │ │ │ │ │ └─────────────────────────┘ │ │ │ │ SFU Benefits: │ │ • Each client uploads once (to SFU) │ │ • SFU forwards to all subscribers │ │ • No transcoding = lower latency │ │ • Bandwidth efficient for many participants │ │ │ │ Regional Deployment: │ │ • SFU servers in each region (us-east, eu-west, ap-southeast) │ │ • Participants connect to nearest SFU │ │ • SFUs interconnect for cross-region rooms │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Regional SFU Edge Signaling Cell for Room State

Cell Architecture Considerations: Video room metadata (who's in the room, permissions) can be cell-based. But the actual media flows through regional SFU servers—these must be as close to participants as possible. A global company might have a meeting with participants in US, EU, and APAC—each connects to their regional SFU, and the SFUs mesh together. Recordings are processed regionally and stored in the customer's designated region for compliance.

Verify & Lookup APIs

Verify API

Purpose: User verification via OTP codes sent over SMS, Voice, Email, WhatsApp, or TOTP. Critical for fraud prevention and 2FA.

Verification Flow SYNC

# Step 1: Create verification service (one-time setup)
POST /v2/Services
FriendlyName=MyAppVerification
CodeLength=6

# Step 2: Start verification (sends code)
POST /v2/Services/{ServiceSid}/Verifications
To=+15551234567
Channel=sms  # or voice, email, whatsapp

Response: { "status": "pending", "sid": "VE123...", "to": "+15551234567" }

# Step 3: Check code (user submits code)
POST /v2/Services/{ServiceSid}/VerificationCheck
To=+15551234567
Code=123456

Response: { "status": "approved", "valid": true }
# or: { "status": "pending", "valid": false } if wrong code

Lookup API

Phone Number Intelligence SYNC

# Basic lookup (formatting, carrier)
GET /v2/PhoneNumbers/+15551234567

Response:
{
  "phone_number": "+15551234567",
  "national_format": "(555) 123-4567",
  "country_code": "US",
  "carrier": {
    "name": "Verizon",
    "type": "mobile",
    "mobile_country_code": "311",
    "mobile_network_code": "480"
  }
}

# Advanced lookup with add-ons
GET /v2/PhoneNumbers/+15551234567?Fields=line_type_intelligence,caller_name

Response includes:
  "line_type_intelligence": { "type": "mobile" },
  "caller_name": { "caller_name": "John Doe", "caller_type": "CONSUMER" }

Backend Architecture

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ VERIFY & LOOKUP ARCHITECTURE │ │ │ │ VERIFY FLOW: │ │ ┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌───────────────────────────┐ │ │ │ API Call │───►│ Customer │───►│ Verify Service│───►│ Channel Delivery │ │ │ │ │ │ Cell │ │ (rate limit, │ │ • SMS: Messaging Pipeline │ │ │ │ │ │ │ │ fraud check) │ │ • Voice: Voice Pipeline │ │ │ └──────────┘ └──────────┘ └───────────────┘ │ • Email: SendGrid │ │ │ │ └───────────────────────────┘ │ │ ▼ │ │ ┌───────────────┐ │ │ │ Code Storage │ │ │ │ (Redis/Dynamo)│ │ │ │ TTL: 10 min │ │ │ └───────────────┘ │ │ │ │ LOOKUP FLOW: │ │ ┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌───────────────────────────┐ │ │ │ API Call │───►│ Customer │───►│ Lookup Service│───►│ Data Sources │ │ │ │ │ │ Cell │ │ (cache first) │ │ • Internal carrier DB │ │ │ │ │ │ │ │ │ │ • Third-party providers │ │ │ └──────────┘ └──────────┘ └───────────────┘ │ • Number portability DB │ │ │ │ └───────────────────────────┘ │ │ ▼ │ │ ┌───────────────┐ │ │ │ Response Cache│ │ │ │ (Redis) │ │ │ │ TTL: 24 hours │ │ │ └───────────────┘ │ │ │ │ Key Characteristics: │ │ • Verify: Stateful (codes stored), fraud detection, rate limiting │ │ • Lookup: Stateless, heavily cached, third-party data aggregation │ │ • Both are GLOBAL services but can route through customer cells │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Cell API Layer Global Verify Service Regional Cache

Cell Architecture Fit: Verify and Lookup APIs route through customer cells for billing and rate limiting, but the actual verification logic and phone number databases are global services. Verification codes are stored in a fast, global cache (DynamoDB Global Tables or Redis) because users might verify from a different region than they requested the code.

Twilio Flex APIs

Purpose: Programmable contact center platform. Flex is a React-based frontend with APIs for task routing, agent management, and omnichannel communication.

Core Concepts

Concept Description API
Workspace Container for contact center config TaskRouter API
Task Unit of work (call, chat, email) TaskRouter API
Worker Agent who handles tasks TaskRouter API
Workflow Rules for routing tasks to workers TaskRouter API
Channel Communication type (voice, SMS, chat) Conversations API

TaskRouter API SYNC

# Create a task (customer contacts you)
POST /v1/Workspaces/{WorkspaceSid}/Tasks
Attributes={"type":"support","priority":1,"customer_id":"C123"}
WorkflowSid=WW123...

# Accept a reservation (agent picks up)
POST /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}/Reservations/{ReservationSid}
ReservationStatus=accepted

# Complete a task
POST /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}
AssignmentStatus=completed

Conversations API ASYNC

# Create conversation (omnichannel thread)
POST /v1/Conversations
FriendlyName=Support-Case-123

# Add participant (customer via SMS)
POST /v1/Conversations/{ConversationSid}/Participants
MessagingBinding.Address=+15551234567
MessagingBinding.ProxyAddress=+15559876543

# Add participant (agent via Flex UI)
POST /v1/Conversations/{ConversationSid}/Participants
Identity=agent@company.com

# Send message
POST /v1/Conversations/{ConversationSid}/Messages
Author=agent@company.com
Body=How can I help you today?

Flex Architecture

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ FLEX ARCHITECTURE │ │ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ FLEX UI (React) │ │ │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ │ │ Agent │ │ Task List │ │ Customer │ │ CRM Panel │ │ Custom │ │ │ │ │ │ Desktop │ │ │ │ Info │ │ │ │ Plugins │ │ │ │ │ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ FLEX BACKEND │ │ │ │ │ │ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ │ │ TaskRouter │ │ Conversations │ │ Flex Insights │ │ │ │ │ │ (Routing) │ │ (Omnichannel) │ │ (Analytics) │ │ │ │ │ └────────┬────────┘ └────────┬────────┘ └─────────────────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ │ │ Underlying Channels │ │ │ │ │ │ Voice │ SMS │ WhatsApp │ Chat │ Email │ │ │ │ │ │ (Each uses respective Twilio API) │ │ │ │ │ └─────────────────────────────────────────────┘ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ Cell Architecture: │ │ • Each Flex customer (contact center) can be a cell │ │ • TaskRouter state is customer-specific │ │ • Conversations span channels but are customer-isolated │ │ • Analytics aggregated per customer │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Cell per Contact Center Regional TaskRouter Global Config

Segment CDP APIs

Purpose: Customer Data Platform. Collects events from all sources, unifies customer profiles, and activates data to 700+ destinations.

Core Concepts

Concept Description
Source Where data comes from (website, mobile app, server)
Destination Where data goes (analytics, marketing, data warehouse)
Track Event call (user did something)
Identify User call (who the user is)
Profile Unified customer record from all sources

Tracking API ASYNC

# Track an event
POST https://api.segment.io/v1/track

{
  "userId": "user_123",
  "event": "Order Completed",
  "properties": {
    "orderId": "ORD-456",
    "total": 99.99,
    "currency": "USD",
    "products": [
      { "sku": "SKU-1", "name": "Widget", "price": 49.99 }
    ]
  },
  "timestamp": "2024-01-15T10:30:00Z"
}

# Identify a user
POST https://api.segment.io/v1/identify

{
  "userId": "user_123",
  "traits": {
    "email": "john@example.com",
    "name": "John Doe",
    "plan": "enterprise",
    "company": {
      "name": "Acme Inc",
      "industry": "Technology"
    }
  }
}

Segment Architecture (Inferred)

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ SEGMENT CDP ARCHITECTURE │ │ │ │ INGESTION LAYER: │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Web SDK │ │ Mobile │ │ Server │ │ Cloud │ │ │ │ (JS) │ │ SDKs │ │ Libraries│ │ Sources │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ │ └─────────────┴─────────────┴─────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ TRACKING API (Edge/Global) │ │ │ │ Low latency, high throughput │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ KAFKA BACKBONE │ │ │ │ • Ingest topic: Raw events │ │ │ │ • Processed topic: Enriched, validated events │ │ │ │ • Per-destination topics: Filtered events │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────┼────────────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌─────────────┐ ┌──────────────┐ │ │ │ RocksDB │ │ Centrifuge │ │ Destination │ │ │ │ (Dedup) │ │ (MySQL-as- │ │ Connectors │ │ │ │ │ │ queue) │ │ (700+) │ │ │ │ 60B keys │ │ │ │ │ │ │ │ per node │ │ Guaranteed │ │ Google Ads │ │ │ │ │ │ delivery │ │ Salesforce │ │ │ │ Prevents │ │ │ │ Snowflake │ │ │ │ duplicate│ │ │ │ etc. │ │ │ │ events │ │ │ │ │ │ │ └──────────┘ └─────────────┘ └──────────────┘ │ │ │ │ PROFILE STORE: │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ Unified Customer Profiles (DynamoDB or custom store) │ │ │ │ • Identity resolution across sources │ │ │ │ • Computed traits │ │ │ │ • Audience membership │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Edge Ingestion Regional Kafka Cell per Workspace

Cell Architecture Fit: Each Segment workspace (customer) can be a cell. Event streams are partitioned by workspace. The Tracking API is global/edge for latency, but downstream processing happens in customer-specific Kafka partitions. RocksDB deduplication is per-workspace. Destinations are workspace-specific. Profile data has strong customer isolation requirements (GDPR).

SendGrid Email APIs

Purpose: Transactional and marketing email delivery at scale. Focus on deliverability, ISP reputation management, and analytics.

Mail Send API ASYNC

# Send email (v3 API)
POST https://api.sendgrid.com/v3/mail/send

{
  "personalizations": [
    {
      "to": [{"email": "john@example.com", "name": "John Doe"}],
      "subject": "Welcome to Our Service"
    }
  ],
  "from": {"email": "noreply@company.com", "name": "Company"},
  "content": [
    {"type": "text/plain", "value": "Welcome!"},
    {"type": "text/html", "value": "

Welcome!

"} ], "tracking_settings": { "click_tracking": {"enable": true}, "open_tracking": {"enable": true} } }

SendGrid Architecture

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ SENDGRID ARCHITECTURE │ │ │ │ ┌──────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────────────┐│ │ │ API Call │───►│ Ingestion │───►│ Message Queue │───►│ MTA Cluster ││ │ │ │ │ (validation, │ │ (prioritized) │ │ (Mail Transfer Agent) ││ │ └──────────┘ │ rate limit) │ │ │ │ ││ │ └───────────────┘ └───────────────┘ │ - IP warming ││ │ │ - ISP throttling ││ │ │ - Feedback loops ││ │ └───────────┬───────────┘│ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────┐│ │ │ DESTINATION ISPs ││ │ │ Gmail │ Outlook │ Yahoo │ Others ││ │ │ ││ │ │ • Reputation management per IP ││ │ │ • Bounce/complaint processing ││ │ │ • Feedback loop handling ││ │ └─────────────────────────────────────┘│ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐│ │ │ EVENT WEBHOOKS ││ │ │ delivered │ opened │ clicked │ bounced │ spam_report │ unsubscribed ││ │ │ ││ │ │ POST to customer webhook with event details ││ │ └─────────────────────────────────────────────────────────────────────────────────┘│ │ │ │ Key Characteristics: │ │ • IP Reputation: Shared vs Dedicated IP pools │ │ • ISP Throttling: Different rates for Gmail vs others │ │ • Bounce Handling: Hard vs soft bounce logic │ │ • Suppression Lists: Global unsubscribes, bounces │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Architecture Tags

Cell per Account Regional MTA Global Suppression

Infrastructure Patterns Summary

Service-to-Infrastructure Mapping

Service Cell Scope Regional Components Global Components
Messaging Customer messages, webhooks Kafka, message processing Super Network (carriers)
Voice Call state, TwiML handling Media servers, SIP gateways PSTN routing, DID inventory
Video Room metadata, permissions SFU media servers Room routing, signaling
Verify Rate limits, billing Code cache Fraud detection, templates
Lookup Rate limits, billing Response cache Carrier databases
Flex TaskRouter, agents Real-time events Configuration
Segment Workspace data, profiles Kafka, destinations Schema registry
SendGrid Customer mail MTA clusters Suppression lists

Cell Architecture Decision Framework

When to put in a Cell:
  • Customer-specific data (messages, calls, events)
  • Customer-specific processing (webhooks, routing logic)
  • Data that needs isolation (compliance, blast radius)
  • State that scales with customer usage
When to keep Regional:
  • Latency-sensitive media processing (voice, video)
  • Carrier connections (can't duplicate for each customer)
  • Message queues (regional Kafka clusters)
  • Caching layers
When to keep Global:
  • Identity and authentication
  • Customer → cell routing tables
  • Shared infrastructure (carrier contracts, IP pools)
  • Configuration that rarely changes

API Gateway Pattern

┌──────────────────────────────────────────────────────────────────────────────────────┐ │ API REQUEST FLOW │ │ │ │ Customer Request │ │ POST /2010-04-01/Accounts/AC123.../Messages.json │ │ Authorization: Basic {AccountSid:AuthToken} │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 1. EDGE (CloudFront / Global Accelerator) │ │ │ │ • TLS termination │ │ │ │ • DDoS protection │ │ │ │ • Geographic routing │ │ │ └────────────────────────────────────────────────────────────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 2. API GATEWAY (Lambda@Edge or Regional API Gateway) │ │ │ │ • Authentication (validate AccountSid:AuthToken) │ │ │ │ • Rate limiting (token bucket per account) │ │ │ │ • Request validation │ │ │ │ • API versioning (extract 2010-04-01 from path) │ │ │ └────────────────────────────────────────────────────────────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 3. CELL ROUTER │ │ │ │ • Lookup: AccountSid → CellId (Redis cache, DynamoDB fallback) │ │ │ │ • Route to correct cell (VPC Lattice by service name) │ │ │ │ • Add headers: X-Twilio-Cell-Id, X-Twilio-Account-Id │ │ │ └────────────────────────────────────────────────────────────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 4. CUSTOMER CELL │ │ │ │ • Version-specific handler (transform request/response) │ │ │ │ • Business logic (create message, queue for delivery) │ │ │ │ • Customer database (Aurora in cell) │ │ │ │ • Webhook dispatch (to customer's StatusCallback URL) │ │ │ │ • Usage metering (async to billing) │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────┘

Interview Talking Points

API Design Insights

  • Date-based versioning allows long-term stability
  • Account scoping enables multi-tenancy at URL level
  • SID prefixes aid debugging across systems
  • Webhook pattern for async status updates
  • TwiML provides domain-specific abstraction

Architecture Insights

  • Cell-based for customer isolation and blast radius
  • Regional for latency-sensitive media
  • Global for shared infrastructure (carriers, identity)
  • Super Network is key differentiator (can't replicate)
  • Async patterns enable scale (store-and-forward)

Key Takeaways

Your Narrative: "Twilio's APIs are the product—they abstract telecommunications complexity behind REST endpoints. The architecture supports this with cell-based isolation for customer data, regional deployment for latency-sensitive media, and global infrastructure for shared carrier connections. Each API product has different characteristics: Messaging is async and tolerates latency; Voice and Video are real-time and require regional media servers; Verify needs global code storage for cross-region verification. Understanding these patterns helps me design APIs that scale while maintaining the developer experience that makes Twilio successful."

Quick Reference

Product Pattern Cell Fit Key Infrastructure
Messaging Async, store-forward Excellent Kafka, Super Network
Voice Real-time, connection Signaling only Media servers (regional)
Video Real-time, streaming Metadata only SFU servers (regional)
Verify Sync request-response Rate limiting Global code cache
Segment Async, event streaming Excellent Kafka, RocksDB
SendGrid Async, batch Good MTA clusters, IP pools