How the interviewer opens it
“Design a service that lets users follow and unfollow accounts. Users can list these relationships and see follower counts. Some accounts have very large numbers of followers.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Relationship rules and access
- Stored scale
- Traffic and read:write ratio
- Latency
- Consistency and availability
- Durability
- Retries and concurrent requests
- List behavior
- Count accuracy
- Deployment and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Follow and unfollow an account
- Check whether any source account follows any target account
- List an account's followers and followed accounts
- Display an account's follower count
Usually out of scope
- Private accounts and follow approval
- Blocks and account deletion
- Feeds, recommendations, and notifications
- Operation across multiple regions
What interviewers ask about
- Account limits
- Several requests can consume the last available slot. Retries and unfollows must not corrupt the source account's total.
- Relationship changes
- The service confirms updates before follower views become current. Failures and old events must not lose or reverse confirmed changes.
- Very large follower lists
- One account can receive 20,000 changes each second. Its list can contain 100 million followers or many inactive relationship records.
- Follower count accuracy
- One account can receive thousands of changes each second. Duplicate events and interrupted count updates can leave a permanent error.
Common mistakes
- Checks the account limit separately from the relationship change.
- Keeps only one relationship index and scans it for the opposite direction.
- Places every celebrity update on one storage partition or one counter.
- Updates two views independently without a durable recovery path.
- Uses offsets or scans inactive history to produce a page.
- Publishes all bucket counts on a timer instead of tracking changed buckets.
The bar by level
- Senior (L5/E5)
- Handles capacity races and retries after later changes. Defines durable events and version rules. Distributes celebrity writes. Bounds page work. Provides count publication with failure recovery.
- Staff (L6+/E6+)
- Quantifies partition capacity and delay budgets. Plans safe bucket changes and live count repair. Defines replay limits and inactive record retention. Proves publication recovery under concurrent changes. Regional ownership is an optional extension.