0% completed
Step 1: System Definition
Email has no owner. A message from a Gmail account to a university address crosses two independent systems, run by organizations that never coordinated, and it arrives because both follow the same protocol. Any service we design is one mail server among millions. It must accept mail from strangers, deliver mail to servers it has never seen, and agree with all of them on the format of a message.
In this case study, we design the backend of a large email service like Gmail, where users send, receive, organize, and search their mail from web, mobile, and desktop clients
.....
.....
.....
chinmay das
· 7 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
· 10 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
· 10 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%