DrawLint.aiTwitter / Social Feed — system design by AgileViper46
Lean HireReviewed by 6 specialized AI reviewers. Explore the diagram and the full per-section feedback below.
Loading diagram…
This is a promising mid-level design because the candidate made several correct high-level choices for the stated feed problem and showed awareness of important tradeoffs. The main gaps are in completeness and scale validation rather than fundamentally wrong architecture, but those gaps are significant enough to keep this below a clear hire.
Core NFR dimensions are explicitly stated
The design clearly calls out latency, availability, and consistency, which are the key non-functional dimensions for this feed system. This gives a solid basis for evaluating tradeoffs instead of leaving them implicit.
Appropriate availability-over-consistency tradeoff
Choosing availability over strict global consistency is a sensible decision for a large-scale social feed. Eventual consistency is acceptable for follower feeds and aligns well with the stated product behavior.
Read-your-own-write consistency is identified
Calling out stronger consistency for the posting user is a good nuance. It shows awareness that feed systems can be eventually consistent overall while still preserving a better user experience for the author.
Availability target is not quantified
The design says availability is important, but does not define a measurable SLA or SLO such as 99.9% or 99.99%. Without a target, it is hard to judge whether the system meets the requirement. Add an explicit availability objective for key user actions like post creation and feed reads.
Latency target is underspecified
The feed generation target of under 500ms is a good start, but it is unclear whether this is p50, p95, or p99, and whether it applies to first-page reads only or also paginated requests. Define percentile-based latency goals per critical API so the requirement is testable and meaningful at 500M DAU scale.
Consistency scope could be stated more precisely
The design mentions eventual consistency and read-your-own-write behavior, but it does not clearly define expected propagation behavior for followers' feeds. A brief statement such as 'followers may see new posts after a short delay' would make the consistency model more complete and easier to validate.
Core nouns match the requirements
The design identifies the key entities needed for this problem: User for account ownership, Post for content creation, and Follow for the uni-directional relationship that drives feed generation. These are the right core nouns for the stated requirements.
No basic capacity numbers provided
The section is empty, so there are no DAU-derived estimates, QPS calculations, or storage/network sizing. For this scale, the candidate should at minimum translate the given assumptions into rough write QPS for post creation, read QPS for feed fetches/page loads, and follower-edge growth/storage.
Cannot validate scale against stated assumptions
With 500M DAU and 2B total users, ballpark sizing matters. Without even rough calculations, there is no way to judge whether the proposed system can handle feed reads, post fanout implications, or data volume. Add back-of-the-envelope estimates such as posts per second from 10M new posts/day, expected feed read amplification from pagination, and storage for posts plus follow relationships.
Feed API includes pagination inputs
Using GET /feed with limit and cursor directly supports the requirement to page through a chronological feed. Cursor-based pagination is a solid choice for feed traversal at large scale.
Post creation flow accounts for multi-step upload
Splitting post creation into start and complete endpoints is a reasonable API pattern when media upload or asynchronous processing is involved, and it can help avoid creating fully visible posts before assets are ready.
Route naming and resource structure are inconsistent
The API mixes singular and plural resources and uses verbs in paths (/posts/start, /posts/complete) while other routes are resource-oriented. This makes the API harder to reason about. A cleaner REST structure would be something like POST /posts to create a draft post and PATCH /posts/{postId} to mark it completed/published.
Follow/unfollow endpoints do not model the uni-directional relationship clearly
PUT /users/{user_id}/followers and DELETE /users/{user_id}/followers are ambiguous because they suggest modifying the target user's follower collection, but the acting user is not represented in the path or request. For a uni-directional follow model, use a clearer resource such as PUT /users/{targetUserId}/follow or POST /follows with followerId/followeeId, and DELETE /follows/{targetUserId} or an equivalent relationship endpoint.
Primary post CRUD coverage is incomplete
The requirements require users to create posts and view feed posts, but the post API surface is incomplete for the primary entity. There is no clear canonical endpoint to fetch a single post by id, and GET /post/{user_id}?post_id={post_id} returning Post[] is awkward for a single resource. Prefer GET /posts/{postId} for a single post and, if needed, GET /users/{userId}/posts for a user's posts.
Response shapes are underspecified for pagination
GET /feed returns Post[] but does not show how the next cursor is returned. To make paging usable, the response should include both items and pagination metadata, for example { items: Post[], nextCursor: string|null }.
User profile posts endpoint naming could be improved
GET /post/{user_id}?post_id={post_id} combines a collection lookup and a single-item filter in one route. If the intent is to view a user's profile posts, a more standard structure would be GET /users/{userId}/posts, optionally with cursor/limit for paging, and a separate GET /posts/{postId} for a single post.
Reasonable fanout-on-write feed architecture
Using a separate feed generation component to populate a user_feed table is a solid high-level choice for chronological home feeds. It aligns well with the requirement to serve feed reads efficiently at very large scale, instead of recomputing the full follow graph on every GET /feed request.
Feed storage modeled for per-user chronological reads
The user_feed table partitioned by user_id and ordered by created_at descending is a good schema direction for paginated chronological feed access. It matches the primary read pattern and keeps the feed service/data model aligned with the functional requirement.
Asynchronous pipeline implied with Kafka
Introducing Kafka between post creation and feed generation is a good architectural pattern for decoupling write traffic from downstream fanout work. At the stated scale, this helps absorb spikes and lets feed generation scale independently from the synchronous post API.
Hot-read optimization with Redis
Adding Redis in front of feed reads is a sensible operational choice for a high-read system. It can reduce repeated database access for the first page or recently accessed feeds and improve latency under heavy DAU.
End-to-end data flow is not fully connected
Several core paths are broken or ambiguous in the diagram: there is no clear connection from the API gateway to Posts service, Follower service, or Feed service; there is no explicit path from Posts service to Kafka/feed generation; and one connection is just empty-to-empty. As drawn, the system does not clearly work end-to-end for create post, follow, and read feed. Fix this by explicitly wiring request flow (client -> gateway -> service), event flow (Posts service -> Kafka -> Feed generation), and follow graph flow (Follower service -> storage/feed generation).
Follower graph storage and usage are architecturally incomplete
The design mentions follower/following entities in annotations, but there is no actual database component or clear service connection shown for persisting and querying follow relationships. Since feed generation depends on knowing who follows whom, this is a fundamental missing architectural piece. Add a concrete follower graph store and connect Follower service to it, then show how Feed generation reads followers of a post author to fan out entries into user_feed.
Multiple orphaned and unnamed components reduce correctness
There are six UNKNOWN nodes with empty labels plus duplicate service boxes that are not meaningfully differentiated. These orphaned/unnamed components make it impossible to verify redundancy, responsibilities, or data flow. Remove unused boxes or label them clearly with their role and connections so the architecture can be evaluated as a coherent system.
Celebrity feed path is not logically integrated
The design hints at a special 'Celebrity feed' using S3/CDN, which can be a valid optimization, but the current flow is inconsistent: clients appear to call S3 directly for GET /feed while CDN also points to clients, and there is no service deciding when to use this path. As a result, this optimization is not operationally complete. Fix by showing Feed service as the decision point that returns either normal feed results from Redis/Cassandra or references to precomputed celebrity content served via CDN/S3.
Pagination mechanism is not shown at the architecture level
The schema ordering by created_at supports pagination, but the HLD does not indicate how Feed service will page through Cassandra partitions safely at scale, such as using cursor/token-based pagination. This does not invalidate the design, but adding the cursor-based read path would make the feed-serving architecture more complete.
Want this kind of feedback on your own design?
Draw your architecture for Twitter / Social Feed and get an instant hire/no-hire signal from 6 specialized AI reviewers — free to start.