0% completed
Gmail: System Definition
Step 1: System Definition
Open your inbox and send a message to someone far away. You do not wait for them to come online, and neither does the system: sending mail is asynchronous. Seconds later, it is sitting in their inbox, ready to open. In this case study, we design that backend. It is a distributed email service like Gmail, built for millions of people who send, receive, and organize messages every day.
The service does three jobs. It accepts incoming mail. It routes each message to the right recipient's storage
.....
.....
.....
chinmay das
· 5 months ago
The design is written in a way that it seems it is trying to predict / guess what gmail might be doing. "It could be doing this or it could be doing that" This is a system design course. Please define the problem scope and constraints. Choose a smaller scope and create a concrete design that matches the scope. For each flow have a description of how the flow works and make it concrete, whether it is synchronous or asynchronous. how is the queuing done, what could be the partition key. And if you want to give additional information you can add in a section for extension points that explain how some feature X can be implemented by adding this extra component.
P B
· 9 months ago
- Lack of deep dive about how we will be performing search in the email body. Only ElasticSearch is mentioned in one place.
- If we are integrating with ElasticSearch anyway, why would we still need SQL and complex indexing. Though later it also mentions "Use inverted indexes: Map keywords -> list of message references. The search service likely maintains multiple indexes: one for email bodies, one for headers, maybe one for senders/recipients for faster specific searches. Querying combines these as needed."
P B
· 9 months ago
The design doesn't mention how bounce would work for incoming emails, whether coming from internal emails or external emails.
Reading Progress
0%