Loading…
Loading…
Add the operations your service exposes. Method, path, and status codes make your API much easier to review.
Policies that aren't specific to a single endpoint — auth, rate limits, versioning, and other notes.
Diagram
Draw the components and how traffic flows between them. Notes below the canvas are optional — the Walkthrough panel is the primary place to narrate flows.
Request walkthrough
Trace each core requirement as an ordered sequence of hops through your diagram. Use component names from your canvas for the From / To columns.
Users can publish posts (text, images, links).
Users can follow/unfollow other users and pages.
Users see a personalized feed of posts from accounts they follow, ordered by relevance/recency.
Feed should include posts from the last 7 days (configurable window).
Storage schema
For each entity, declare how it's stored. Sharding key is the interesting one — pick the access pattern it optimises for.
Posts content and follows other users.
A piece of content (text, image, link) published by a user.
A directed relationship: follower → followee.
A per-user ordered list of post IDs representing their personalized timeline.
Component choices
Pick one per row and give a one-line reason. These are the concrete technology decisions your diagram implies.
How traffic is distributed to your app servers.
Where hot reads are served from.
Async work buffer for writes/fan-out.
Primary durable store for entities.
Your diagram
No components drawn yet — edit the diagram before answering.
Iterate on your design — don't start over.
Each scenario below probes a specific weakness in a typical HLD. Reference components from your diagram by name, describe what breaks and at what load, then name the minimum change that fixes it. Strong answers identify the precise failure mode — not just "scale it up".
The Redis node holding user A's feed cache goes down. What does user A see?
Probes: failure mode analysis