Meta’s Monolith vs Uber’s Microservices
The 'Monolith vs Microservices' debate is back in a big way! Was it even stopped? Can there be a clear winner? Let's find out.
Almost a year ago, we saw how the Prime Video team at Amazon replaced their microservices with Monolith.
This move saved them a staggering 90% on infrastructure costs!
Here, we should remember that Amazon Prime is still a microservices application with one of the services refactored like a monolith.
Meanwhile, we find out that Meta used monolithic architecture to ship Threads in only five months.
And now, Uber has built scalable, real-time chat using microservices to improve customer experience.
It's clear that both architectures have their own strengths and weaknesses; to provide you with a comprehensive perspective,
In today’s newsletter, we’ll cover
Meta used monolithic to ship Threads in only 5 months
Best microservices examples and lessons learnt
Uber builds scalable chat using microservices
Let’s get started!
Meta used monolithic to ship Threads in only 5 months
With Elon Musk's acquisition of Twitter causing chaos, Meta saw an opportunity to develop a competing service.
However, they had to make a fast move to attract Twitter users looking for alternatives.
At first, Meta tried to improve text-based posts on Instagram. However, the efforts didn't bring about enough new users.
So, they decided to recycle existing Instagram backend components and infrastructure for Threads.
Meta formed a small team primarily focusing on reusing Instagram's capabilities to deliver Threads quickly and efficiently.
Threads technology stack
The tech stack of Threads is quite similar to that of Instagram, featuring monolithic application components and dedicated data stores.
The key components include --
Distillery (a custom Django Framework),
WWW (an older PHP component),
TAO (a write-through cache for graph data model),
UDB (a sharded MySQL deployment for data storage),
ZippyDB (a key-value cache for transient data), and
Async (a serverless function compute platform for asynchronous jobs)
Threads utilized a Server-Driven UI (SDUI) approach to enable rapid experimentation and testing cycles. During this quick adjustment phase, they collected feedback from thousands of company employees.
Although reusing Instagram's components and infrastructure accelerated the development of Threads, Meta also acquired substantial tech debt through this process.
The team is now gradually separating Threads' data models from Instagram's, aiming to untangle the shared resources between the two platforms.
Threads' grand launch to becoming one of the fastest-growing apps ever
The Threads launch experienced a few issues, such as users in some regions downloading the app before the intended launch time due to time zone confusion.
The engineers also worked on the scalability of some processes to allow importing followers from Instagram.
Despite the challenges, it was the most successful app launch of all time, pulling in over 100M users in its first five days.
Threads has since introduced new features, such as — the "following" feed, trending conversations, and limited API access for reading and writing posts. Moreover, the team is actively working on adopting the ActivityPub protocol to enable cross-platform sharing between Threads and other social networks supporting the protocol.
Find out more about the Thread’s architecture, here and here too.
Best microservices examples and lessons learnt from them
Microservice implementation needs elaborate planning and consideration of the existing systems and organizational structure. Here are 6 examples with critical lessons to enable your microservice implementations.
Lyft transitioned from a monolithic architecture to microservices to enhance iteration speeds but faced productivity challenges as services scaled. To address this, they focused on improving critical touchpoints in the development process, implementing localized development, efficient developer loops, and testing automation, highlighting the importance of these strategies for enhancing iteration and delivery times.
Twitter adopted microservices to accelerate API releases but faced challenges with fragmentation and productivity. So, it implemented a decoupled architecture with dedicated resources and pluggable components, emphasizing the importance of managing microservice fragmentation and optimizing API releases for efficiency.
Capital One migrated to AWS and implemented containerization for quicker app releases, integrating various services like cloud-based call centers and machine learning algorithms. They learned to employ microservice containerization, utilize Docker for automation, and leverage Amazon ECS for managing container deployments, highlighting the importance of these practices for improving time-to-market and flexibility.
Uber adopted Domain-Oriented Microservice Architecture (DOMA) to address challenges with scaling and productivity, reducing feature onboarding time by 25-30% and organizing 2200 microservices into 70 domains. The lessons learned emphasize the importance of DOMA in reducing feature onboarding time and integrating shared business logic through domain gateways.
Etsy implemented a two-layer API structure with meta-endpoints to enhance rendering time, addressing the need for improved concurrency and processing time. By combining microservices with decoupled meta-endpoints, Etsy achieved a rendering time of 1000 ms, highlighting the benefits of an API-first architecture for processing user requests efficiently.
PayPal restructured releases and developed smaller deployable apps, but managing them became cumbersome. They accelerated microservices adoption by creating the open-source framework "Kraken," followed by "Altus" for robust dependency management. Ultimately, they established a common platform with PayPal as a Service (PPaaS) and emphasized the importance of individual services, automation, and innovative tools for improving release times and executing code organization.
Read more details on these and other 6 examples, here.
Uber builds scalable chat using microservices
Uber decided to break away from its legacy architecture, which relied on the WAMP protocol.
In the past, Uber's customer interactions were split across different channels, with only 1% of customers accessing the live chat, 58% seeking help via in-app messaging, and the remaining users utilizing other support channels.
The legacy architecture experienced problems with message delivery, observability, and an incredibly low throughput of 10 transactions per second (tps). Also, outdated WAMP protocol and libraries negatively affected insights and debugging capabilities.
Transitioning to a GraphQL Subscription Service allowed them to improve live chat customer support and achieve better performance and reliability.
The goals of Uber's new architecture
Uber's main objective was to initially increase the percentage of live chat support to 40% of all customer contacts. Eventually, they aimed to move 80% of those interactions to live chat within twelve months.
In the new architecture, Uber wanted to achieve observability and debuggability from the onset. Additionally, they aimed to implement stateless services while achieving a message-delivery success rate surpassing 95.5%.
The components of the new architecture are:
1. Front-end UI and back-end microservices -
Uber's new architecture includes a front-end User Interface for agents and various back-end microservices.
The Chat Channel Manager, Contact Service, and Router handle customer contacts and allocate them to available agents.
The Agent State Service tracks active agent sessions.
Apache Kafka is utilized to facilitate event/notification publishing, and for synchronization between routing and agent state tracking.
2. Introducing the GraphQL Subscription Service -
The heart of Uber's solution is the GraphQL Subscription Service, which enables bidirectional communication using WebSockets and integrates with the graphql-ws library.
To ensure reliability, the team at Uber implemented several enhancements, including automatic reconnections to resume interrupted chats and heartbeats between the agent's browser and the chat service.
Uber's engineering team conducted comprehensive load testing before implementing the new architecture in a live environment.
The tests confirmed that the solution could support at least 10,000 connections on a single server and provide horizontal scalability. They also invested resources in enhancing system observability to gain comprehensive insights into system performance and Service Level Agreements (SLAs).
And the results?
Now, Uber can successfully manage 36% of the overall contact volume using its live chat channel.
Additionally, the error rates for message delivery decreased dramatically from 46% to 0.45%, signifying a major improvement in reliability.
Find out more about this implementation here.