# Design a follower and following service: system design interview question

> A directed account graph with reliable changes, account limits, large follower lists, and accurate follower counts.

Source: https://sysround.com/questions/design-follower-and-following-service
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** 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+:** 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.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=follow-service


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.