Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
POST /api/v1/post
PUT /api/v1/post
DELETE /api/v1/post
POST /api/v1/like?postID
DELETE /api/v1/like?postID
POST /api/v1/comment?postID
PUT /api/v1/comment?postID
DELETE /api/v1/comment?postid
GET /api/v1/feed?limit=
GET /api/v1/shareLink
WS /api/v1/notify
CDN: It is used to host the frontend of the service. The response is fast because it is in edge locations. Most of the time it handles 80% of the reads since it can cache as well. Media is also served using CDN only
API Gateway: To route traffic based on the endpoint getting hit. Used for authentication and for rate limiting the requests.
Kafka: It is used as a high throughput queue to store the requests that are received. With this even if there is a down time it is easy to recover as kafka will have the missed requests. User will receive 200 OK
Redis:To cache the requests and take care of concurrent redundant requests and reduce load on the db and response time. and to store sorted sets so that delivery is fast.
Blob Storage: Great way to store the media that is uploaded into the platform we can use services like S3 for this.
Feed Generator: Generates feed by taking in the incoming data from the Post service and Comment service. Is used by the Feed service. We will be using the Hybrid fan-out strategy where we will push to every follower's feed for normal users and pull at read time for celebrity.
Feed service: Uses the Feed Generator service generated data. Checks the redis first if not hit goes to Mongo and then makes an entry in redis so as to the next hit happens successfully at redis itself.
Mongo: Document DB used for this use case.
Comment Service: This service handles the comment creation and everything related to it. Be it a comment on a post or a reply to a comment.
Post service → persist to Mongo → upload media to S3 → emit NewPost event to Kafka → 200 OK. The event is what triggers fan-out
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
We will use Mongo DB to store the data. For images/videos we will store them in the object store
POST:
postID
Title
Body
Attachment URL
Visibility
CreatedAt
UpdatedAt
Likes:
ID
PostID
CreatedAt
UpdatedAt
Comments:
commentID
Body
PostID
CreatedAt
UpdatedAt
no per-user feed cache needed; feed assembled on read.
visibility is checked at read time during feed assembly — the merge logic verifies the viewer's relationship to the author before emitting each post, and never trusts a cached feed blindly.
Followers:
ID
FolloweeID
Feed Generator: Generates the feed for the user. Generates feed by taking in the incoming data from the post service and is used by the Feed service. We will be using the Hybrid fan-out strategy where we will push to every follower's feed for normal users and pull at read time for celebrity.
If the ranking service is slow, we circuit-break to recency-based ordering and cap candidate count.
fetch in parallel from multiple shards/leaves and K-way merge into one page.
We will be keeping the comments in the db with its id and if it has any reply its id will be present otherwise it will be empty. In this way a relationship is maintained.
Notification Service: This is used to notify the users about their posts likes, dislikes, comments, followed etc., We will be fanning it out to the followers if its a post through push strategy.
If a action fails we even retry it for a set amount of times lets say 3. If it fails more than that set limit it will go to the DLQ. We will be retrying using exponential backoff with jitter to avoid multiple retries at the same time. This will prevent any load on the respective service.
We will be having replicas to adhere to high availability so that when ever a service fails it's replica takes over. We can go even further by having regional failovers so that if a region goes down we can switch to the other region.
We will be using sharded counters for upvotes and downvotes to avoid hot spots created due to viral posts. we will be spliting it into N shards and increment independently. We will flush aggregates to durable storage on a timer.
The counters will be having idempotency key as well to avoid double counting. If a operation fails in the middle we will be having an idempotency check to see if its already done if so we will just return that result we stored.