msys — Meta's Shared Mobile Messaging Layer

msys is the name of a project initiated in 2018 by Messenger engineers at Meta. Its stated goal was to change the status quo in which each app built messaging separately, by creating a foundational messaging layer shared across Meta's family of apps. Meta operates many messaging experiences, including the dedicated Messenger and WhatsApp apps, feed-style apps such as Instagram and Facebook, Facebook Lite and Instagram Lite, and Metaverse-focused experiences such as the Meta Quest companion app. Over its first five years the effort saw both successes and challenges, reaffirming benefits of sharing mobile-product code while also revealing unexpected obstacles.

• Project initiated in 2018 by Messenger engineers
• Aim: one foundational messaging layer shared across apps
• Spans dedicated messaging apps, feed-style apps, Lite apps and the Meta Quest companion app

Outside observers often assume a single codebase powers messaging everywhere at Meta, but the article explains that the default has been for each app to build and iterate independently. Counting messaging experiences means multiplying the number of apps by the number of surfaces in each app, such as Android, iOS, MacOS and the web. Independent development persisted for reasons connected to Meta's "Move Fast" culture: it keeps the barrier to trying ideas low and lets well-funded teams progress on surface-specific features in parallel. In many cases, however, that freedom produced divergences with little value, complicating work for both product teams and the infrastructure teams supporting them.

• Surfaces counted include Android, iOS, MacOS and WWW
• Earlier convergence efforts had limited success
• Divergence created burdens of code duplication

The article uses Messenger's mobile clients to illustrate the cost of duplicated code. For years the two apps shared the same contract with the server but had completely different architectures for processing updates, largely because separate teams had developed them. On iOS, server payloads were held in memory and displayed in the UI before being persisted to disk, giving low sync latency and a simple, reliable pipeline, but also a persistent class of missing-message bugs that appeared only on app restart. On Android, payloads were persisted to disk before rendering, which ensured consistency across restarts at the cost of latency.

• Same server contract, different update-processing architectures
• iOS: in-memory first, lower sync latency, restart-related missing message bugs
• Android: disk-first, restart consistency, higher latency

The "Messaging at Scale" article is published under @Scale Conferences' articles for 2023 and is credited to the @Scale team. It walks through the msys journey, covering technical strategies, key results and the most notable learnings. Its sections address the recent history of mobile messaging code sharing at Meta, the growing burdens of code duplication, the design of the platform and the wider msys ecosystem. It also includes a case study on bringing msys to Facebook, followed by discussion of what went wrong, finding a balance and what comes next.

• Designing the platform
• The msys ecosystem
• Case study: bringing msys to Facebook
• What went wrong and finding a balance

msys is an internal engineering project at Meta rather than a product offered to the public, so there is no pricing, application process or set of customer requirements described in the source material. Public information about it is published as an article on the @Scale Conferences website. Readers can find the full account, including the Facebook case study and the team's learnings, on the "Messaging at Scale" page.

• Published on atscaleconference.com
• Article type: Articles; year: 2023
• Attributed to the @Scale team