Snapchat is well-known among tweens and teenagers. You’re probably above 25 if you can’t figure out how it works. Snapchat, one of the most popular social media applications, provides kids and adolescents exactly what they want: an easy method to share ordinary occurrences while also making them appear cool.
Unlike Facebook and Twitter, which record and publish everything you do, Snapchat employs messages that are supposed to vanish (see how they don’t).
There is a lot about Snapchat, and if you are a developer it’s even more. So, this post will give you a high-level view of Snapchat system design and much more insights.
Snapchat is a U.S.-based social networking app that lets users connect immediately, share images, and more.
- Messages and images (or snaps) have a 24-hour time limit. Encourages people to share their stories in groups.
- Snap Map allows users to see on a map where their pals are.
- Memories remind users of photos they saved or shared a year later.
- Snapchat is extremely popular with younger generations, especially teens. There are 319 million active users on the app, and 5.4 billion snaps are sent every day.
Important Design Terms
Monolithic Architecture – A single-tiered application that operates independently of other applications is known as a monolith (monolithic architecture). A monolith is designed to perform and handle all of the activities required to complete a task. The application performs all functions from beginning to end.
Microservices – It polar opposite of monoliths. Microservices is an architectural approach that organizes an application as a collection of services. These services are used to control many aspects of an application. A customer places an order, a waiter takes it and delivers it, and a chef prepares it. In this example, each component functions independently and separately from the others; no one knows exactly what the others are doing, and no one has access to the same information.
Orchestration: The technique of automating many operations is known as orchestration. These jobs include computer system and software configuration, coordination, and administration.
Proxy: A proxy acts as a go-between between a client looking for a resource and the server that provides it.
Mesh: A service mesh is a software architecture pattern that adds a layer to an infrastructure layer to allow regulated, observable, and secure communication between services through proxy.
Snapchat originated as a cloud-based monolith based on the Google App Engine. However, as the program grew in popularity and gained more users and data, scalability became an issue.
Additionally, with a huge explosion radius within the monolith, system-wide disturbances were more possible. One of Snapchat’s problems was defined as a “tragedy of the commons,” in which features competed for access to resources; features were loading at app launch time, allowing certain features to load faster but the others to load slower.
Engineers also sought clear visibility, separation, and ownership of their components from a development standpoint, so that the service could be flexible and efficient.
As Snapchat expanded, the firm realized it needed to break down its monolithic infrastructure into smaller, more efficient pieces. In order to provide decreased latency, the organization decided to develop a microservices-based design.
To fulfill those goals, Snapchat opted to update its software using Amazon DynamoDB, a scalable NoSQL database service. The firm was able to reduce median latency by 20% as a result of its efforts.
The app was rewritten into numerous smaller applications by the corporation. Snapchat began with numerous applications, including a camera, chat, memories, picture editing, content consumption, and a map. Though integrating these programs into a single monolith was convenient for consumers, it posed a severe technical issue in terms of maintaining good performance.
For a rewrite, the corporation established many ground rules. Don’t preload; each feature should be its own app, and it should be quick. Snapchat halted modifications in several places to enable the rewrite, making it strictly a technical task.
Additional features integration
Snapchat’s camera app has lenses, filters, bitmojis, and the ability to add augmented reality animations, among other things. Snapchat’s chat app also allows users to store photographs, save talks, add emoticons, and more.
Snapchat’s map, among other things, allows you to monitor pals if they want you to. Memories, photo editing, and content consumption are all separate Snapchat apps with their unique capabilities.
Memories allow you to store or modify photographs or videos for later use, as well as upload or send them. Users can also utilize picture editing to cut films, add text, add stickers, and more.
Snapchat’s external content consumption refers to what it shows users based on a range of parameters.
The program depended extensively on JSON to perform network queries at the time. However, parsing JSON was time-consuming and inefficient. Snapchat used a centralized network management API to mask the use of JSON as an implementation detail to tackle this problem.
Microservices introduce the challenges of application state management, service communication, and failure management. Snapchat used open-source technologies like Temporal to overcome orchestration difficulties in order to build a strong and dependable system.
As a result, the organization decided to use a service mesh design pattern. Snapchat used Envoy, another open-source tool that acts as a proxy, to achieve this pattern. Envoy managed the flow of service traffic via the infrastructure, giving developers visibility into potential difficulties.
Snapchat created an internal app called the Switchboard within the service mesh. Switchboard served as a control panel for Snap’s services, allowing users to shift traffic, manage service dependencies (a feature that allows one service to be managed dependent on the condition of others), and drain regions.
To simplify the complexity of potential configurations within services, Switchboard was utilized instead of exposing the whole Envoy API. Snap has a common internal and regional network for its microservices thanks to the service mesh.
Services inside the same region could connect with one another without using the public Internet, and no external network traffic could communicate with internal network parts.
Only the Gateways would be authorized to expose themselves to the internet for security reasons. The API gateways, for example, might easily serve as front doors, processing requests from clients/users and routing them along with the network.
Network & API Gateway
All queries from the Snapchat client come through API Gateway. It uses the same Envoy image and connects to the same Control Plane as our internal microservices. Our Control Plane allows us to enable custom Envoy filters.
Snapchat’s authentication systems, as well as our rate limiting and load shedding technologies, are handled by these filters. Envoy uses the Service Mesh to route requests to the relevant microservice after the filter chain is complete.
Snapchat’s API gateway routes external traffic to the app’s many functionalities. Users’ requests to modify configuration states are managed by servers, which then provide data and information back to the app’s numerous services.
Overall, Snapchat’s present design may be compared to several programs running on a single operating system, which in this case is the Snapchat app. I tried very hard to provide you with a high-level overview of the Snapchat system design. I hope you found it useful.