{"title":"Design Instagram","description":null,"content":"\n> **QUESTION**\n>\n> #### What is Instagram?\n>\n> [Instagram](https://www.instagram.com/) is a social media platform focused on sharing photos and short videos. Users can upload media, apply filters, add captions, follow other users, and engage through likes, comments, and direct messages.\n>\n> \n> \n> \n>\n> Over time, it has expanded to include features such as stories, reels, live streaming, and recommendations.\n\n\nIn this chapter, we will walk through the **high-level design of a photo-sharing platform like Instagram.**\n\nWhile Instagram supports a wide range of features including direct messaging, Reels, and Stories, this article will primarily focus on **the core functionality of photo and video sharing**.\n\nLet’s start by clarifying the requirements.\n\n---\n\n# 1. Requirement Clarification\n\nBefore diving into the design, lets outline the functional and non-functional requirements.\n\n\n### Functional Requirements\n\n1. Users can **upload** photos and videos.\n2. Users can add **captions** to their posts.\n3. Users can **follow/unfollow** other users.\n4. Users can **like**, **share**, and **comment** on posts.\n5. Support for multiple images/videos in a single post (carousel).\n6. Users can view a **personalized** **feed** consisting of posts from accounts they follow.\n7. Users can **search** by username and hashtag.\n\n### Non-Functional Requirements\n\n1. **Low Latency: **The feed should load fast (~100ms).\n2. **High Availability: **The system should be available 24/7 with minimal downtime.\n3. **Eventual Consistency: **A slight delay in users seeing the latest posts from accounts they follow is acceptable.\n4. **High Scalability: **Handle millions of concurrent users and billions of posts.\n5. **High Durability: **The uploaded photos/videos shouldn’t be lost.\n\n\n#### Out of Scope\n\n1. Direct messaging.\n2. Short-form video content (Reels).\n3. Push Notifications for likes, comments, and follows.\n\n---\n\n# 2. Capacity Estimation\n\n### User Base\n\n- **Total Monthly Active Users (MAUs):** 2 billion\n- **Daily Active Users (DAUs):** → **500 million users/day**\n\n### Estimating Read & Write Requests\n\n#### Post Uploads (Writes)\n\n- 100M media uploads/day\n- Each upload generates metadata writes (DB + cache)\n- **Total write requests:** 100M uploads + 100M metadata writes = 200M writes/day\n\n#### Feed Reads\n\n- Assume an average user scrolls through 100 posts per session\n- 500 million DAUs × 100 posts viewed = 50B feed requests/day\n- Assuming 80% of feed reads are served from cache, backend reads = 10B DB reads/day\n\n### Estimating Storage Requirements\n\n#### Assumptions\n\n- 20% of DAUs (100M) upload media every day\n- 80% of uploads are photos, 20% are videos\n- **Average photo size:** 1MB\n- **Average video size:** 10 MB\n\n#### Daily Storage Calculation\n\n- **Photos:** (100M × 80%) × 1 MB = 80 TB/day\n- **Videos:** (100M × 20%) × 10 MB = 200 TB/day\n- **Total storage per day:** 280 TB/day\n\n#### Database Storage\n\n- **Metadata per post:** ~500 bytes (caption, timestamp, author, engagement counts)\n- **Total posts in a year:** 100M × 365 = 36B posts\n- **Metadata storage per year:** 90 TB/year\n\n#### Caching Requirements\n\n- **Hot cache size:** Store recent & popular 1 billion posts\n- Assume each cached post takes 2 KB (post data + engagement counts)\n- Cache size = 2 TB for active posts (Redis/Memcached)\n\n---\n\n# 3. High Level Design\n\nThe diagram below maps the major components and their connections, from the clients and API Gateway through the core services, data stores, and CDN.\n\n\n```mermaid\nflowchart TB\n CLIENTS[Clients
Web / Mobile]:::rose\n LB[Load Balancer
API Gateway]:::primary\n\n CLIENTS --> LB\n\n subgraph CORE[\"Core Services\"]\n direction TB\n USER[User Service]:::orange\n ENG[Engagement Service]:::orange\n POST[Post Service]:::orange\n FEED[Feed Service]:::orange\n SEARCH[Search Service]:::orange\n end\n\n LB --> USER\n LB --> ENG\n LB --> POST\n LB --> FEED\n LB --> SEARCH\n\n MQ[(Message Queue)]:::green\n POST --> MQ\n MQ --> FEED\n ENG --> MQ\n\n USERCACHE[(User Cache)]:::teal\n USERDB[(User DB)]:::teal\n USER --> USERCACHE --> USERDB\n\n LIKEDB[(Like / Comment DB)]:::teal\n ENG --> LIKEDB\n\n POSTCACHE[(Post Metadata Cache)]:::teal\n POSTDB[(Post Metadata DB)]:::teal\n POST --> POSTCACHE --> POSTDB\n\n FEEDCACHE[(Feed Cache)]:::teal\n FEED --> FEEDCACHE\n\n SIDX[(Search Index)]:::teal\n SCACHE[(Search Cache)]:::teal\n SEARCH --> SIDX\n SEARCH --> SCACHE\n\n CDN[CDN]:::secondary\n OBJ[(Object Storage
media files)]:::teal\n CLIENTS --> CDN\n CDN --> OBJ\n POST --> OBJ\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef rose fill:#f783ac,stroke:#000,color:#000\n```\n\n\n### Components\n\n#### 1. Clients (Web, Mobile)\n\nUsers interact with the platform through web browsers or mobile apps. The client applications handle video playback, user interactions like likes and comments, and UI rendering, communicating with backend services through an **API Gateway** or **Load Balancer**.\n\n#### 2. Load Balancer / API Gateway\n\nActs as the single entry point for all client requests. It distributes incoming traffic across multiple service instances for **high availability** and **scalability**, and enforces **rate limiting**, **authentication**, and **authorization** before forwarding requests to downstream services.\n\n#### 3. User Service\n\nStores and manages **user authentication, profile data, and social connections** (follow/unfollow).\n\n#### 4. Post Service\n\nHandles **photo/video uploads** and stores metadata such as caption, user info, and timestamps. It coordinates the upload of media files from the user's device to **Object Storage (e.g., AWS S3)** and updates metadata in a **database**. It also uses a message queue such as **Kafka** to notify the Feed Service when a new post is created.\n\n#### 5. Feed Service\n\nPrecomputes and stores user feeds in a high-performance cache such as Redis or Memcached to enable fast retrieval, and queries the database if a feed is not cached.\n\n#### 6. Engagement Service\n\nManages **likes, comments, and shares**, and writes engagement data to a high-throughput database asynchronously via a message queue.\n\n#### 7. Search Service\n\nAllows users to search for other users, hashtags, and posts. It uses **Elasticsearch** to index and retrieve data quickly, and supports **autocomplete and full-text search** for a better user experience.\n\n#### 8. Message Queue\n\nDecouples services and enables event-driven processing. It notifies the **Feed Service** of new posts and updates engagement data asynchronously.\n\n#### 9. Object Storage & CDN\n\nPhotos and videos are stored in distributed object storage such as S3 or Google Cloud Storage, and a **CDN (Cloudflare, AWS CloudFront)** ensures fast delivery globally.\n\n---\n\n# 4. Database Design\n\nA large-scale content platform like Instagram requires handling both **structured data** (e.g., user accounts, post metadata) and **unstructured/semistructured data** (e.g., photos, videos, search indexes).\n\nTypically, you’ll combine multiple database solutions to handle different workloads.\n\nGiven the requirements, we will use a **relational database (e.g., PostgreSQL, MySQL)** for structured data and a **NoSQL database (Cassandra, DynamoDB, or Elasticsearch)** for feed storage and search indexing.\n\n## 4.1 Relational Database for Structured Data\n\nGiven the structured nature of user profiles and posts metadata, a relational database (like **PostgreSQL** or **MySQL**) is often well-suited.\n\n\n```mermaid\nerDiagram\n USERS {\n bigint user_id PK\n varchar username\n varchar full_name\n varchar email\n varchar profile_pic_url\n varchar password_hash\n date created_at\n }\n POSTS {\n bigint post_id PK\n bigint user_id FK\n varchar caption\n bigint like_count\n date created_at\n }\n MEDIA {\n bigint media_id PK\n bigint post_id FK\n enum media_type\n varchar media_url\n }\n COMMENTS {\n bigint comment_id PK\n bigint post_id FK\n bigint user_id FK\n text content\n date created_at\n }\n SHARES {\n bigint share_id PK\n bigint post_id FK\n bigint user_id FK\n text content\n date created_at\n }\n FOLLOWERS {\n bigint follower_id PK\n bigint followee_id PK\n double engagement_score\n date created_at\n }\n\n USERS ||--o{ POSTS : \"creates\"\n POSTS ||--o{ MEDIA : \"has\"\n POSTS ||--o{ COMMENTS : \"receives\"\n POSTS ||--o{ SHARES : \"shared as\"\n USERS ||--o{ COMMENTS : \"writes\"\n USERS ||--o{ SHARES : \"shares\"\n USERS ||--o{ FOLLOWERS : \"follows\"\n```\n\n\n- **Users Table: **Stores user account details.\n- **Posts Table: **Stores metadata related to posts.\n- **Media Table: **Stores photo/video metadata, but not the actual files.\n- **Comments Table: **Stores post comments.\n- **Shares Table: **Stores post shares.\n- **Followers Table: **Maintains the follow/unfollow relationship. Stores engagement score from followers to help with ranking posts in the feed.\n\n## 4.2 NoSQL Databases for High-Volume Data\n\nWhile relational databases are ideal for structured data, they struggle with high-velocity writes and large scale distributed workloads. NoSQL databases like **Cassandra, DynamoDB, or Redis** provide horizontal scalability and high availability.\n\nTo reduce **feed generation latency**, a **denormalized feed table** stores precomputed timelines:\n\n\n```json\n{\n \"user_id\": 56789,\n \"feed\": [\n {\"post_id\": 111, \"user_id\": 123, \"media_url\": \"s3://path1\", \"caption\": \"Hello world\"},\n {\"post_id\": 112, \"user_id\": 234, \"media_url\": \"s3://path2\", \"caption\": \"Sunset view\"}\n ]\n}\n```\n\n\nThis table is updated **asynchronously** via **Kafka** when a user posts, and cached **in Redis for quick retrieval**.\n\n#### Using Graph Databases for Social Connections\n\nTo support complex relationship queries, such as mutual friends, suggested followers, and influencer ranking, we can use a **graph database** like Neo4j or Amazon Neptune.\n\nThey efficiently model follower-following relationships with nodes and edges.\n\n**Example Query: \"People You May Know\"**\n\n\n```shell\nMATCH (me:User {id:12345})-[:FOLLOWS]->(friend)-[:FOLLOWS]->(suggested)\nWHERE NOT (me)-[:FOLLOWS]->(suggested)\nRETURN suggested LIMIT 5\n```\n\n\nThis allows **real-time friend suggestions** without complex SQL joins.\n\n## 4.3 Search Indexes\n\nTo support fast and scalable search queries, we can use **Elasticsearch**, a distributed, real-time search engine optimized for full-text searches.\n\nEach user profile and post metadata can be stored as a document in an Elasticsearch index, allowing quick lookups and advanced filtering.\n\n#### Example: Storing User Data in Elasticsearch\n\n\n```json\n{\n \"user_id\": 12345,\n \"username\": \"john_doe\",\n \"full_name\": \"John Doe\",\n \"bio\": \"Photographer | Traveler\"\n}\n```\n\n\nTo support trending hashtags and keyword searches, we can store **hashtags** in a separate Elasticsearch index.\n\n**Example:**\n\n\n```json\n{\n \"hashtag\": \"#travel\",\n \"post_count\": 1500000,\n \"last_used\": \"2025-03-20T12:00:00Z\"\n}\n```\n\n\n## 4.4 Media Storage\n\nInstagram handles **petabytes of photos/videos**, requiring a **durable and low-latency storage solution**.\n\nA **distributed object storage system**, such as **Amazon S3**, is well-suited for storing media files. It supports **pre-signed URLs**, enabling users to upload media directly without routing through application servers, reducing load and latency.\n\nTo ensure **high durability**, media files are stored in multiple replicas across different data centers, protecting against data loss.\n\nTo further optimize read latency, content can be cached closer to users using a **Content Delivery Network (CDN)** like **Cloudflare or Amazon CloudFront**. This reduces load times and improves the user experience, especially for frequently accessed media.\n\n---\n\n# 5. API Design\n\n### 5.1 Get User Profile\n\nFetching a user's profile requires a valid JWT token; the response returns core account fields including follower and following counts.\n\n\n```shell\nGET /api/v1/users/{user_id}\nAuthorization: Bearer JWT_TOKEN\n```\n\n\n**Response:**\n\n\n```json\n{\n \"user_id\": 12345,\n \"username\": \"john_doe\",\n \"full_name\": \"John Doe\",\n \"profile_pic\": \"https://cdn.example.com/profile.jpg\",\n \"followers_count\": 200,\n \"following_count\": 150\n}\n```\n\n\n### 5.2 Follow a User\n\nA POST to the follow endpoint records the relationship between the authenticated user and the target account, and no request body is required.\n\n\n```shell\nPOST /api/v1/users/{user_id}/follow\nAuthorization: Bearer JWT_TOKEN\n```\n\n\n### 5.3 Create a New Post\n\nThis endpoint accepts multipart form data so that both caption text and media files can be submitted in a single request.\n\n\n```shell\nPOST /api/v1/posts\nAuthorization: Bearer JWT_TOKEN\nContent-Type: multipart/form-data\n```\n\n\n**Form Data:**\n\n\n```shell\ncaption: \"Sunset at the beach\"\nmedia: [image1.jpg, video1.mp4]\n```\n\n\n**Response:**\n\n\n```json\n{\n \"post_id\": 98765,\n \"message\": \"Post uploaded successfully\"\n}\n```\n\n\n### 5.4 Get a Post by ID\n\nThis endpoint retrieves the full metadata for a single post, including media URLs, like count, and comment count.\n\n\n```shell\nGET /api/v1/posts/{post_id}\n```\n\n\n**Response:**\n\n\n```json\n{\n \"post_id\": 98765,\n \"user_id\": 12345,\n \"caption\": \"Sunset at the beach\",\n \"media\": [\n \"https://cdn.example.com/photo1.jpg\",\n \"https://cdn.example.com/video1.mp4\"\n ],\n \"likes_count\": 500,\n \"comments_count\": 120\n}\n```\n\n\n### 5.5 Get User Feed\n\nPaginated via `page` and `limit` query parameters, this endpoint returns a personalized list of posts from accounts the authenticated user follows.\n\n\n```shell\nGET /api/v1/feed?page=1&limit=10\nAuthorization: Bearer JWT_TOKEN\n```\n\n\n**Response:**\n\n\n```json\n[\n {\n \"post_id\": 123,\n \"user\": {\n \"user_id\": 56789,\n \"username\": \"travel_lover\"\n },\n \"caption\": \"Exploring the mountains!\",\n \"media\": [\"https://cdn.example.com/photo123.jpg\"],\n \"likes_count\": 1200,\n \"comments_count\": 85\n },\n {\n \"post_id\": 124,\n \"user\": {\n \"user_id\": 98765,\n \"username\": \"foodie_dude\"\n },\n \"caption\": \"Delicious sushi!\",\n \"media\": [\"https://cdn.example.com/photo124.jpg\"],\n \"likes_count\": 980\n }\n]\n```\n\n\n### 5.6 Like a Post\n\nSending a POST to this endpoint records a like from the authenticated user on the specified post, with no request body needed.\n\n\n```shell\nPOST /api/v1/posts/{post_id}/like\nAuthorization: Bearer JWT_TOKEN\n```\n\n\n### 5.7 Comment on a Post\n\nPosting a comment requires a JSON body containing the comment text; the endpoint accepts `application/json` as the content type.\n\n\n```shell\nPOST /api/v1/posts/{post_id}/comment\nAuthorization: Bearer JWT_TOKEN\nContent-Type: application/json\n```\n\n\n\n```json\n{\n \"content\": \"Amazing shot!\"\n}\n```\n\n\n### 5.8 Get Comments for a Post\n\nComments are returned in paginated order; each item includes the commenter's ID, username, text content, and timestamp.\n\n\n```shell\nGET /api/v1/posts/{post_id}/comments?page=1&limit=10\n```\n\n\n**Response:**\n\n\n```json\n[\n {\n \"comment_id\": 65432,\n \"user\": {\n \"user_id\": 12345,\n \"username\": \"john_doe\"\n },\n \"content\": \"Amazing shot!\",\n \"created_at\": \"2025-03-18T12:34:56Z\"\n },\n {\n \"comment_id\": 65433,\n \"user\": {\n \"user_id\": 67890,\n \"username\": \"nature_lover\"\n },\n \"content\": \"Breathtaking view!\"\n }\n]\n```\n\n\n### 5.9 Search Users\n\nA GET request with the `q` query parameter returns matching user profiles ranked by relevance, powered by Elasticsearch under the hood.\n\n\n```shell\nGET /api/v1/search/users?q=john\n```\n\n\n**Response:**\n\n\n```json\n[\n {\n \"user_id\": 12345,\n \"username\": \"john_doe\",\n \"full_name\": \"John Doe\",\n \"profile_pic\": \"https://cdn.example.com/profile.jpg\"\n }\n]\n```\n\n\n---\n\n# 6. Design Deep Dive\n\n## 6.1 Photo/Video Upload\n\n1. **User Initiates the Upload**\n 1. The user selects one or more photos or videos and enters a caption.\n 2. The client (mobile app/web browser) sends an upload request to the API Gateway.\n2. **API Gateway Handles the Request**\n 1. The API gateway authenticates and validates the request.\n 2. Routes the request to the Post Service.\n3. **Post Service Generates a Pre-signed URL**\n 1. Instead of uploading media directly through the backend, the Post Service generates pre-signed URLs from Object Storage (one per media file).\n 2. It sends the pre-signed URLs back to the client.\n4. **Client Uploads Media to Object Storage**\n 1. The client directly uploads each file in parallel to Object Storage via the pre-signed URLs.\n 2. This reduces backend load and enables faster parallel uploads.\n 3. Once all uploads are complete, the client sends a confirmation request to the backend with all media URLs.\n5. **Post Service Saves Metadata in the Database**\n 1. The Post Service stores post metadata (caption, timestamp, user ID) in the Posts table and stores each media file separately in the Media Table.\n6. **Kafka Publishes a \"New Post\" Event**\n 1. The Post Service sends an event to Kafka, notifying the Feed Service.\n\n## 6.2 Newsfeed Generation\n\nSince users follow both normal users and celebrities, the system must mix posts efficiently.\n\n### Fan-out-on-write (Push Model) for Normal Users\n\nFor **normal users** with a manageable number of followers, we use **fan-out-on-write**, meaning posts are **pushed** to followers’ feeds at the time of posting.\n\n#### How It Works\n\n1. User A posts a new photo/video.\n2. The Post Service sends an event to Kafka, notifying the Feed Service.\n3. The Feed Service identifies the users followers (e.g., 500 followers).\n4. The post is immediately inserted into each follower’s timeline, stored in Redis (hot cache).\n5. When followers open their feeds, posts are instantly available, ensuring low-latency reads.\n\n**Example: LPUSH - Add Post to Followers’ Feeds**\n\nSuppose user `12345` (John Doe), who has 500 followers, posts a new photo. The Feed Service pushes this post to all 500 followers' feeds.\n\n\n```shell\nLPUSH feed:56789 \"{'post_id': 98765, 'author': 'john_doe', 'media_url': 'https://cdn.instagram.com/photo98765.jpg', 'caption': 'Sunset at the beach!', 'timestamp': '2025-03-20T14:30:00Z'}\"\n\nLPUSH feed:67890 \"{'post_id': 98765, 'author': 'john_doe', 'media_url': 'https://cdn.instagram.com/photo98765.jpg', 'caption': 'Sunset at the beach!', 'timestamp': '2025-03-20T14:30:00Z'}\"\n\nLPUSH feed:78901 \"{'post_id': 98765, 'author': 'john_doe', 'media_url': 'https://cdn.instagram.com/photo98765.jpg', 'caption': 'Sunset at the beach!', 'timestamp': '2025-03-20T14:30:00Z'}\"\n\n...\n```\n\n\nHere, John's post is pushed to the feeds of followers `56789`, `67890`, and `78901`, along with 497 other followers.\n\n**Example: Fetching a User’s Feed (LRANGE - Get Recent Posts)**\n\n\n```shell\nLRANGE feed:56789 0 9 # Fetch the latest 10 posts from user 56789's feed\n```\n\n\n**Benefits:** Reads are fast since followers' feeds are pre-loaded, and the approach works well for small and medium-sized accounts.\n\n**Challenges:** It becomes inefficient for users with millions of followers, such as celebrities. Writing a single post requires copying it to potentially millions of timelines, which leads to high write amplification.\n\n### Fan-out-on-read (Pull Model) for Celebrities\n\nFor **celebrities and influencers**, where a single post may need to reach **millions of followers**, preloading into every follower’s feed is impractical.\n\nInstead, a **fan-out-on-read (pull model)** is used.\n\n#### How It Works\n\n1. When a user requests their newsfeed, the Feed Service dynamically retrieves normal users’ posts from Redis (precomputed feeds) and celebrity posts from a hot cache (Redis) or a persistent store (PostgreSQL).\n2. The system merges both types of posts in real-time before serving the feed.\n\n**Benefits:** It avoids massive write operations, which keeps the system scalable, and it serves fresh data when users request their feeds.\n\n**Challenges:** Read latency is slightly higher than the push model, and it requires caching optimization to reduce database lookups.\n\n## 6.3 Search\n\n### Indexing New Content\n\n1. **A New Post/User is Created**\n 1. A user uploads a post or creates an account.\n 2. The Post/User stores metadata in the database.\n 3. The Post/User Service publishes an event to Kafka.\n2. **Search Service Updates Elasticsearch Index**\n 1. The Search Service consumes Kafka events and adds new users, posts, or hashtags to Elasticsearch.\n\n### Search Request\n\n1. **User Initiates a Search Request**\n 1. The user types a query in the search bar (e.g., `\"john_doe\"` or `\"#travel\"`).\n 2. The client (mobile/web) sends a request. The request is routed via the API Gateway to the Search Service.\n2. **Search Service Queries Elasticsearch**\n 1. The Search Service first checks Redis Cache for recent searches. If not found, queries Elasticsearch for relevant results.\n 2. Elasticsearch performs full-text search, prefix matching and ranking based on engagement/popularity.\n3. **Elasticsearch Returns Results**\n 1. Elasticsearch returns ranked results matching the query.\n 2. The Search Service formats the response.\n4. **Search Results are Cached in Redis**\n 1. The Search Service caches frequent queries in Redis for faster lookups.\n 2. Next time a user searches for the same query, the result is served from Redis instantly.\n\n## 6.4 Like, Comments and Shares\n\nThe **Engagement Service **processes like, comment and share requests.\n\nIt sends a Kafka event to update the DB asynchronously.\n\n**Like event:**\n\n\n```json\n{\n \"event\": \"POST_LIKED\",\n \"user_id\": 12345,\n \"post_id\": 67890\n}\n```\n\n\n**Share event:**\n\n\n```json\n{\n \"event\": \"POST_SHARED\",\n \"user_id\": 12345,\n \"post_id\": 67890\n}\n```\n\n\n**Comment event:**\n\n\n```json\n{\n \"event\": \"POST_COMMENTED\",\n \"user_id\": 12345,\n \"post_id\": 67890,\n \"comment_id\": 99999,\n \"content\": \"Amazing shot!\"\n}\n```\n\n\nTo optimize the latency for popular posts, we can cache like / share count and top comments.\n\n---\n\n# 7. Follow-ups\n\n## 7.1 Scalability\n\nScalability ensures the system can handle increasing load without degrading performance.\n\n#### Horizontal Scaling (Scale Out)\n\nUse distributed databases like Cassandra or DynamoDB to spread data across nodes, and deploy multiple instances of each service behind a load balancer to handle user requests.\n\n#### Sharding\n\nShard large datasets to split them across nodes:\n\n- User Data → Shard by `user_id mod N`\n- Posts → Shard by `post_id mod N`\n- Followers Table → Shard by `follower_id mod N`\n\n#### Microservices Architecture\n\nBreak the system into independent services such as the Feed Service, Post Service, and User Service to improve maintainability and scalability. Use message queues like Kafka or RabbitMQ to handle high-throughput operations asynchronously, including notifications, updates, and feed generation.\n\n## 7.2 Availability\n\nAvailability ensures that Instagram remains accessible 24/7, even in the face of failures. Given its global user base, the platform must achieve atleast 99.99% uptime.\n\n#### Redundancy & Replication\n\nMaintain replicated databases across multiple regions, such as PostgreSQL replicas and Cassandra multi-region clusters, and deploy multiple application servers across different availability zones (AZs).\n\n#### Failover Mechanisms\n\nUse automatic failover in databases, such as a leader-follower setup in PostgreSQL or multi-leader Cassandra clusters, and implement circuit breakers to gracefully degrade service if a dependency fails.\n\n## 7.3 Durability\n\nDurability ensures that data, especially user-generated content (photos, videos, comments, likes), is never lost, even in case of system failures.\n\n#### Distributed Object Storage\n\nStore media in Amazon S3 or Google Cloud Storage, which replicates data across multiple locations to prevent loss.\n\n#### Database Replication & Backups\n\nUse multi-region replication across Cassandra, DynamoDB, or PostgreSQL replicas for disaster recovery, and perform regular backups to prevent accidental data loss.\n\n#### Write-Ahead Logging (WAL) & Event Sourcing\n\nImplement WAL in databases so that changes are recorded before they are committed, and use event sourcing to log user actions like new posts and likes so that state can be rebuilt if necessary.\n\n---\n\n# Quiz","pageType":"system-design-interviews"}

Get Premium