Recommended Free Tools
Facebook’s 2014 Messenger redesign replaced repeated, bulky conversation refreshes with a mobile-first flow: an app received a conversation snapshot, then got smaller updates pushed over MQTT. Meta said the changes cut non-media data use by 40% and reduced by about 20% the number of people experiencing errors when sending messages. Those figures describe Meta’s own 2014 report, not independent tests or Messenger’s current performance.
What the 2014 redesign changed
The redesign addressed two connected bottlenecks: how Messenger clients received conversation updates and how the system delivered recent messages while storing longer-term history.
From repeated refreshes to pushed updates
In the older flow, a lightweight push notification prompted the app to make a more complex HTTPS request. The server returned a large JSON response containing an updated conversation view. The redesigned client first received a message snapshot, then received incremental updates—called “deltas”—over MQTT. The app applied each delta to its local copy rather than repeatedly fetching a large view.
| Design area | Earlier approach | 2014 redesign |
|---|---|---|
| Client updates | A push notification triggered an HTTPS request for a large JSON conversation response. | An initial snapshot was followed by pushed MQTT deltas that updated the client’s local copy. |
| Message encoding | JSON. | Thrift for messages and deltas; Meta said this reduced on-wire payload size by roughly 50%. |
| Recent delivery and storage | The traditional disk tier served conversation updates as well as history. | Iris handled ordered recent updates and let app delivery and disk storage advance independently. |
Meta’s engineering post described the design goal this way: “Extending desktop-focused infrastructure for a mobile world could work well, but building new mobile first infrastructure with protocols designed for pushable devices offers even better experiences.” The post did not identify an individual speaker.
#1 Best Overall
How Iris separated delivery from storage
The server-side system, Iris, was a totally ordered queue of message updates. It tracked separate progress pointers for delivery to apps and for writing updates to traditional storage. Because those activities could advance at different rates, slower disk writes did not have to hold up real-time delivery.
- Recent updates were served from Iris.
- If the app was offline or there was a disk outage, Iris’s backing store could cover about a week.
- Older message history and full inbox snapshots remained on the traditional disk tier.
What Meta reported about the results
Meta reported that the redesign led to 40% lower non-media data usage and approximately 20% fewer people experiencing errors when trying to send a message. These are company-reported outcomes in Meta’s 2014 engineering account; they should not be read as independently measured figures or as a guarantee about present-day Messenger.
How this fits Facebook’s earlier messaging work
Facebook had already redesigned messaging infrastructure before the 2014 Messenger work. The earlier projects addressed different systems and should not be treated as one continuous description of Messenger’s architecture.
2010: Messages combined multiple channels
Facebook’s 2010 Messages redesign brought chat, SMS, email, and Messages together in a real-time conversation. The engineering account says the team evaluated MySQL, Cassandra, HBase, and other systems, then chose HBase for the workload and its scaling and consistency characteristics. Application servers coordinated message sources and services such as attachment storage, user discovery, relationships, privacy, and delivery decisions.
Rank #3
Facebook’s 2010 post reported more than 350 million users sending more than 15 billion person-to-person messages per month, and more than 300 million chat users sending more than 120 billion messages per month. Those are historical figures published in 2010, not current usage statistics.
2011: A broader application backend
A 2011 account described application servers handling queries and writes, with supporting services for email parsing, user-to-cell discovery, cache invalidation, and social and user indexing. Operational tools supported cell management, hardware changes, monitoring, and rolling deployments. These details describe a separate backend account; they are not all specifications of the 2014 Messenger redesign.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Messenger’s later encryption-related infrastructure work
In a December 6, 2023 post, Meta said it had begun upgrading personal Messenger conversations to end-to-end encryption by default. It described rebuilding application protocols and designing Labyrinth, an encrypted server-side message-history store intended to support multi-device access and key rotation when a client device is removed.
Meta also discussed challenges involving web clients, feature support, endpoint management, telemetry, and application security. That post documents Meta’s design and rollout statements at that time; it does not establish Messenger’s current encryption coverage.
Free tools Windows power users keep installed
One-click scans. No signup required.
What this history does—and does not—tell you
The 2014 redesign is a historical account of how Meta adapted messaging infrastructure for mobile clients: snapshot plus pushed deltas on the client side, and an ordered queue that decoupled recent delivery from longer-term storage on the server side. It is not a description of current Messenger internals. The 2010 and 2011 posts cover distinct earlier work, while the 2023 post covers a later encryption-related architectural effort.
Quick Recap
- Meta Engineering: Building Mobile-First Infrastructure for Messenger (October 9, 2014)
- Facebook Engineering: The Underlying Technology of Messages (2010)
- Facebook Engineering: The Backend of Messages (2011)
- Meta Engineering: Building End-to-End Encryption for Messenger (December 6, 2023)
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

