How Twitter Scales to 3,000 Images per Second: Architecture Secrets Revealed

Background

In 2012 Twitter was a text‑only service. By 2016 it introduced rich media support—photos, animated GIFs, Vine videos, and embedded videos—through a self‑built Media Platform.

Key Challenges of the Old Design

Coupled upload : Tweets and media were uploaded together, wasting bandwidth and making retries costly.

Poor scalability : The monolithic endpoint could not handle larger media such as video, especially in low‑bandwidth markets.

Inefficient internal bandwidth : Media payloads traversed many services not designed for large binary data, reducing overall efficiency.

Unbounded storage growth : Images persisted forever in BlobStore, even after tweets were deleted, leading to massive storage bloat.

Inflexible variant handling : Adding new image sizes required storing a new copy for every image, limiting feature agility.

Design Principles Introduced

Decouple media from tweets to allow independent optimization.

Use handles (mediaId) instead of moving large data blocks.

Adopt chunked resumable uploads to reduce failure rates.

Generate image variants on demand and set a 20‑day TTL for most variants, saving storage and compute.

Employ progressive JPEGs and WebP where supported to reduce payload size.

Old Architecture (2012)

Write Path (Old)

Clients sent tweets and attached images to a monolithic endpoint, which then routed the request through multiple services, causing bandwidth waste and scaling limits.

Read Path (Old)

Clients fetched image variants from a CDN, which often had to retrieve the original from BlobStore, adding latency and limiting flexibility.

New Architecture (2016)

Write Path (New)

Media upload is a first‑class operation with its own endpoint that stores raw files in BlobStore and returns a mediaId .

When creating a tweet, the client includes the mediaId instead of the raw file, eliminating unnecessary data movement.

Image Service generates variants (small, medium, large) and stores them in BlobStore; VideoBird handles video transcoding.

Chunked resumable upload allows users to pause and resume after network interruptions, dramatically lowering failure rates in emerging markets.

Chunked Resumable Upload

Upload is split into small chunks (e.g., three parts); each chunk is appended to the same mediaId.

After all chunks are received, the upload is finalized and the media becomes usable.

This approach reduces upload failure rates by up to 33% in Brazil, 30% in India, and 19% in Indonesia for files larger than 50 KB.

Read Path (New)

Clients request image variants from a CDN backed by MinaBird, which can generate missing variants on‑demand via ImageBird and VideoBird, enabling efficient storage and rapid content removal when required.

Variants are kept for 20 days; after that only the original remains, cutting daily storage growth from 6 TB to 1.5 TB.

The 20‑day TTL saved Twitter about $6 million in 2015.

Client Improvements (Android)

Adopted WebP format, reducing image size by ~25% and improving engagement in low‑bandwidth markets.

Experimented with progressive JPEG (PJPEG), which streams a low‑quality preview quickly and refines it progressively, offering better performance and easier backend support.

Using Facebook’s Fresco library, PJPEG’s first scan is only ~10 KB, cutting load times and error rates significantly.

This translation is based on Todd Hoff’s article “How Twitter Handles 3,000 Images Per Second”.