# Design a decentralized social network like Mastodon: system design interview question

> Independent servers exchange social events despite peer failures, delayed events, duplicate events, and limits on remote deletion.

Source: https://sysround.com/questions/design-decentralized-social-network-like-mastodon
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a social network whose independently operated servers exchange posts and follow events. Users can follow users on other servers and delete their own posts."

## What to clarify first

- Network and server scale
- Traffic and read:write mix
- Feed size and follow distribution
- Payload, destinations, and retention
- Product behavior
- Latency and consistency
- Durability
- Peer outages
- Deletion guarantees and operating limits
- Trust, protocol, and exclusions

## Scope of a strong answer

Core requirements:

- Publish public text posts and show a local feed
- Follow and unfollow users on other servers
- Exchange events despite peer failures
- Apply post deletions on servers that follow the protocol

Usually out of scope:

- Private posts and direct messages
- Media storage
- Post edits
- Search and account moves

## What interviewers probe

### Delivery to remote servers

One post can reach thousands of independent servers. Uncertain acknowledgments and long outages must not stop local actions or healthy traffic.

### Follow state across servers

Follow, acceptance, and cancellation can arrive in different orders. An old event must not change a newer relationship.

### Post deletion

Deletion can precede creation or follow a long outage. Remote deadlines need clear operating limits, and independent operators control their own copies.

### Local feeds

Follow counts vary widely. A cheap post write can create expensive feed reads or a large burst of local updates.

## Common mistakes

- Assumes a central server can order events or enforce rules across all operators.
- Makes local requests wait for remote peers.
- Treats event arrival order as the correct order for follows and deletions.
- Confuses asynchronous database replication with durable acknowledgment across independent machines.
- Promises deletion deadlines without bounds on traffic, peer latency, or queue delay.
- Claims that a feed query meets its latency target without follow counts, page size, or peak load.

## The bar by level

- **Senior:** Resolves follow races and deletion before creation. Preserves acknowledged work across one machine failure. Sizes peer backlogs correctly and selects a feed path from the workload.
- **Staff+:** Defines authority, repair, and retention rules across operators. Derives deletion deadlines from traffic limits, peer latency, and reserved capacity. Separates live deadlines from repair. Addresses safe failover, peer abuse, and limits on remote erasure.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=decentralized-social-network


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