Meta System Design Interview: 15 Questions Asked in 2026

Meta's system design round is the most critical part of the on-site loop. You get 45 minutes to design a scalable system from scratch — and the interviewer expects you to cover requirements, architecture, deep dives, and trade-offs. This post breaks down 15 real system design questions asked at Meta, along with detailed solutions, common mistakes, and a minute-by-minute walkthrough.

Meta System Design Interview Format

The system design round at Meta follows a structured 45-minute format. You're expected to drive the conversation — the interviewer will challenge your choices and ask follow-ups.

Meta System Design Round Flow

flowchart TD
    A["Problem Statement - 2 min"] --> B["Requirements & Scope - 5 min"]
    B --> C["High-Level Design - 10 min"]
    C --> D["API & Data Model - 5 min"]
    D --> E["Deep Dive - 15 min"]
    E --> F["Trade-offs & Bottlenecks - 5 min"]
    F --> G["Wrap-up & Questions - 3 min"]
    G --> H["Score & Decision"]

Key expectations by level:

What Meta Looks For in System Design

Meta evaluates system design on four core criteria. Each carries equal weight — weak performance in one area can sink your candidacy.

1. Problem Definition

Clarify requirements before designing. Ask about:

• Scale (daily active users, QPS, storage)
• Features (core vs nice-to-have)
• Constraints (latency, availability, consistency)

"Don't assume the interviewer's definition of the problem matches yours. Spend 5 minutes aligning."

2. High-Level Design

Draw the major components and data flow. Show you can:

• Identify the right services (API gateway, application servers, databases)
• Choose the right storage (SQL vs NoSQL, caching layers)
• Handle read-heavy vs write-heavy patterns

3. Deep Dive

Pick 1-2 components and go deep. Common areas:

• Data partitioning and replication
• Consistency models (strong vs eventual)
• Caching strategies (write-through, write-back, cache-aside)
• Real-time vs batch processing

4. Trade-offs

Every design has trade-offs. Explicitly state:

• Availability vs consistency (CAP theorem)
• Latency vs throughput
• Cost vs performance
• Complexity vs simplicity

"Meta interviewers respect candidates who acknowledge trade-offs rather than pretending one solution is perfect."

15 Real Meta System Design Questions

1. Design News Feed (Facebook/Instagram)

Problem: Design the news feed system that shows personalized posts from friends, pages, and groups.

Key Components:

• Post Service — Handles creating, storing, and retrieving posts
• Fan-out service — Pushes posts to followers' feeds (push vs pull model)
• Feed cache — Redis cluster storing pre-computed feeds per user
• Ranking service — ML model that scores posts by relevance
• Media service — Handles photos, videos, links

Architecture:

• Write path: User posts → Post Service → Fan-out service → pushes to follower feeds
• Read path: User requests feed → Feed cache → returns ranked posts
• Fan-out on write for users with < 10K followers; fan-out on read for celebrities

Scaling Challenges:

• Celebrity problem: A post by a celebrity with 100M followers can't be pushed to all followers
• Hot keys: Trending posts create cache stampedes
• Real-time: New posts must appear within seconds

Trade-offs:

• Push model: Fast reads, slow writes, stale feeds
• Pull model: Fresh feeds, slow reads, high compute
• Hybrid: Push for regular users, pull for celebrities

Common Mistakes:

• Ignoring the celebrity problem
• Not separating write path from read path
• Forgetting about pagination (use cursor-based, not offset)
• Not considering feed diversity (don't show 20 posts from same user)

2. Design Messenger/WhatsApp

Problem: Design a real-time messaging system supporting 1:1 and group chats.

Key Components:

• Connection service — Manages WebSocket connections between clients
• Message service — Stores messages, handles delivery
• Presence service — Tracks online/offline status
• Media service — Handles image, video, file uploads
• Push notification service — Sends notifications to offline users

Architecture:

• Client connects to connection server via WebSocket
• Connection server maintains mapping: user → connection server
• Message routing: sender → connection server → recipient's connection server → recipient
• Messages stored in distributed database (Cassandra) with message ordering

Scaling Challenges:

• Maintaining millions of WebSocket connections
• Message ordering across distributed servers
• Group chat fan-out (message sent to 1000-person group)
• Offline message delivery

Trade-offs:

• WebSocket vs polling: WebSocket is real-time but harder to scale
• Single leader vs multi-leader replication: Single leader for consistency, multi-leader for availability
• End-to-end encryption vs server-side search: E2E encryption prevents server-side indexing

Common Mistakes:

• Not handling connection drops and reconnection
• Ignoring message ordering guarantees
• Forgetting about group chat scalability
• Not considering read receipts and typing indicators

3. Design Instagram Stories

Problem: Design the Stories feature — ephemeral content that disappears after 24 hours.

Key Components:

• Story service — Handles story creation and expiration
• Story feed service — Aggregates stories from followed users
• Media pipeline — Processes images/videos, generates thumbnails
• Expiration service — Deletes stories after 24 hours
• View tracking service — Tracks who viewed each story

Architecture:

• Stories stored with TTL (time-to-live) in database
• Story feed pre-computed and cached per user
• Media stored in CDN with origin in object storage
• Viewers list stored separately, loaded on demand

Scaling Challenges:

• High write throughput (millions of stories/day)
• Expiration at scale (millions of stories expire simultaneously)
• Real-time story feed updates
• Media processing pipeline latency

Trade-offs:

• Pre-compute story feed vs compute on-demand: Pre-compute for speed, on-demand for freshness
• Store viewers list eagerly vs lazily: Eagerly for instant display, lazily for storage savings
• CDN caching vs origin hits: CDN for performance, origin for fresh content

Common Mistakes:

• Not handling story expiration properly
• Ignoring re-sharing stories (reshare to your story)
• Forgetting about story highlights (persistent stories)
• Not considering privacy (close friends, restricted audiences)

4. Design Facebook Live/Video Streaming

Problem: Design a live video streaming platform supporting millions of concurrent viewers.

Key Components:

• Ingestion service — Receives video stream from broadcaster
• Transcoding service — Converts to multiple resolutions
• CDN distribution — Delivers video to viewers globally
• Chat service — Real-time comments during live stream
• Notification service — Alerts followers when someone goes live

Architecture:

• Broadcaster pushes RTMP stream to ingestion server
• Ingestion server segments video into chunks
• Transcoding produces multiple quality levels (240p, 480p, 720p, 1080p)
• CDN caches and delivers chunks to viewers
• Adaptive bitrate streaming (HLS/DASH) based on viewer bandwidth

Scaling Challenges:

• Ingestion: Handling millions of concurrent streamers
• Transcoding: CPU-intensive, needs GPU clusters
• CDN: Global distribution with low latency
• Chat: Millions of messages per minute on popular streams

Trade-offs:

• Transcode on-demand vs pre-transcode: On-demand saves compute, pre-transcode reduces latency
• RTMP vs WebRTC: RTMP is mature but higher latency, WebRTC is low latency but harder to scale
• Centralized vs edge transcoding: Centralized is simpler, edge reduces bandwidth

Common Mistakes:

• Not handling stream failures and reconnection
• Ignoring latency (goal: < 5 seconds end-to-end)
• Forgetting about DVR functionality (rewind live stream)
• Not considering DMCA/copyright detection

5. Design Facebook Marketplace

Problem: Design a platform for buying and selling items locally.

Key Components:

• Listing service — Handles item creation, search, and filtering
• Search service — Full-text search with geo-location
• Messaging service — Buyer-seller communication
• Payment service — Handles transactions and escrow
• Recommendation service — Suggests relevant listings

Architecture:

• Listings stored in Elasticsearch for full-text search
• Geo-indexing for location-based queries
• Images stored in CDN with object storage origin
• Messaging integrated with Messenger
• Payment processing with escrow for safety

Scaling Challenges:

• Search performance across millions of listings
• Geo-spatial queries (listings near me)
• Image storage and delivery
• Fraud detection and trust scoring

Trade-offs:

• Elasticsearch vs PostgreSQL full-text: Elasticsearch is faster for search, PostgreSQL is simpler
• Geo-hash vs quad-tree: Geo-hash is simpler, quad-tree is more efficient for dense areas
• Escrow vs direct payment: Escrow is safer but adds complexity

Common Mistakes:

• Not handling duplicate listings
• Ignoring search relevance (price, distance, freshness)
• Forgetting about listing expiration and renewal
• Not considering mobile vs web experience

6. Design Facebook Groups

Problem: Design a group system supporting millions of members with posts, events, and moderation.

Key Components:

• Group service — Handles group creation, membership, settings
• Post service — Manages group posts and comments
• Membership service — Handles join requests, roles, permissions
• Moderation service — Auto-detects spam, handles reports
• Event service — Group events and RSVPs

Architecture:

• Group data stored in relational database (membership, settings)
• Posts stored in Cassandra for write-heavy workload
• Feed service generates group-specific feeds
• Moderation uses ML models for content classification
• Push notifications for new posts and events

Scaling Challenges:

• Large groups (millions of members) with high post volume
• Notification management (don't spam members)
• Moderation at scale (thousands of posts/day)
• Group discovery and recommendation

Trade-offs:

• Public vs private groups: Public is discoverable, private is exclusive
• Push vs pull for group feeds: Push is faster, pull is fresher
• Auto-moderation vs human moderation: Auto is faster, human is more accurate

Common Mistakes:

• Not handling group roles (admin, moderator, member)
• Ignoring group privacy settings
• Forgetting about group archives
• Not considering cross-posting to news feed

7. Design Notification System

Problem: Design a system that sends notifications across multiple channels (push, email, SMS, in-app).

Key Components:

• Notification service — Orchestrates notification delivery
• Channel services — Push (APNs/FCM), email (SES), SMS (Twilio), in-app
• User preference service — Manages notification settings
• Template service — Renders notification content
• Delivery tracking service — Tracks open rates, click rates

Architecture:

• Notification created with metadata (user, type, channel, content)
• Router determines channels based on user preferences
• Rate limiter prevents notification fatigue
• Delivery service sends via appropriate channel
• Analytics pipeline tracks delivery and engagement

Scaling Challenges:

• High throughput (millions of notifications/day)
• Multi-channel delivery (different SLAs per channel)
• User preference management
• Rate limiting and throttling

Trade-offs:

• Immediate vs batched delivery: Immediate is faster, batched reduces load
• Push vs email: Push is instant but intrusive, email is less intrusive but slower
• Single channel vs multi-channel: Multi-channel increases reach but complexity

Common Mistakes:

• Not handling notification preferences
• Ignoring rate limiting (notification fatigue)
• Forgetting about delivery failures and retries
• Not considering timezone differences

8. Design Photo/Video Storage (CDN)

Problem: Design a media storage system serving billions of photos and videos.

Key Components:

• Upload service — Handles media upload and processing
• Storage service — Stores originals in object storage
• CDN — Caches and delivers media globally
• Transformation service — Resizes, crops, filters
• Metadata service — Stores EXIF data, tags, locations

Architecture:

• Upload goes to ingestion server
• Original stored in object storage (S3)
• Transformation pipeline generates thumbnails and multiple sizes
• CDN caches transformed media at edge locations
• Metadata stored in separate database for search

Scaling Challenges:

• Storage costs at exabyte scale
• CDN cache hit ratio optimization
• Transformation pipeline throughput
• Global distribution with low latency

Trade-offs:

• Eager vs lazy transformation: Eager is faster for reads, lazy saves storage
• CDN vs origin: CDN is faster, origin is always fresh
• Compression vs quality: Higher compression saves bandwidth but reduces quality

Common Mistakes:

• Not handling upload failures and retries
• Ignoring image format optimization (WebP vs JPEG)
• Forgetting about content moderation
• Not considering storage lifecycle (hot vs cold storage)

9. Design Ad Click Aggregation

Problem: Design a system that tracks ad clicks and aggregates metrics for advertisers.

Key Components:

• Click tracking service — Logs every ad click
• Aggregation service — Computes metrics (CTR, spend, impressions)
• Real-time dashboard — Shows live metrics to advertisers
• Attribution service — Links clicks to conversions
• Budget service — Manages ad spend and pacing

Architecture:

• Click events sent to Kafka for real-time processing
• Flink/Spark Streaming aggregates metrics in real-time
• Aggregated data stored in ClickHouse for fast queries
• Batch pipeline for daily/weekly rollups
• Dashboard queries aggregated data, not raw clicks

Scaling Challenges:

• High write throughput (millions of clicks/second)
• Real-time aggregation latency
• Query performance across time ranges
• Deduplication (bot clicks, accidental clicks)

Trade-offs:

• Real-time vs batch aggregation: Real-time is fresher, batch is cheaper
• Exact vs approximate counting: Exact is accurate, approximate is faster
• Push vs pull for dashboards: Push is instant, pull is simpler

Common Mistakes:

• Not handling click fraud and bot detection
• Ignoring attribution window logic
• Forgetting about budget pacing
• Not considering cross-device tracking

10. Design People You May Know

Problem: Design a friend recommendation system based on social graph.

Key Components:

• Graph service — Stores social connections
• Recommendation service — Computes friend suggestions
• Feature service — Extracts signals (mutual friends, workplace, school)
• Ranking service — Scores and ranks recommendations
• Feedback service — Tracks accept/ignore rates

Architecture:

• Social graph stored in Neo4j or similar graph database
• Features computed offline (mutual friends, shared groups, location)
• Recommendation engine runs batch jobs nightly
• Real-time adjustments based on recent interactions
• A/B testing framework for algorithm tuning

Scaling Challenges:

• Graph traversal at scale (billions of edges)
• Fresh recommendations (new connections should update suggestions)
• Privacy (don't suggest people based on private information)
• Cold start (new users with few connections)

Trade-offs:

• Batch vs real-time recommendations: Batch is cheaper, real-time is fresher
• Precision vs recall: High precision means fewer but better suggestions, high recall means more suggestions
• Privacy vs relevance: More data means better suggestions but privacy concerns

Common Mistakes:

• Not handling blocked users
• Ignoring "already friends" filtering
• Forgetting about recommendation diversity
• Not considering user fatigue (too many suggestions)

11. Design Rate Limiter

Problem: Design a distributed rate limiter protecting APIs from abuse.

Key Components:

• Rate limiter service — Enforces rate limits per user/IP/endpoint
• Configuration service — Stores rate limit rules
• Counter service — Tracks request counts
• Token bucket service — Implements token bucket algorithm
• Logging service — Tracks rate limit violations

Architecture:

• Rate limiter sits in API gateway
• Rules configured per endpoint (e.g., 100 requests/minute per user)
• Counters stored in Redis for distributed access
• Token bucket algorithm allows bursts up to limit
• Violations logged for monitoring and alerting

Scaling Challenges:

• Distributed counters (consistency across nodes)
• Sub-millisecond latency requirement
• Dynamic rate limits (adjust based on load)
• Multi-tenant rate limiting

Trade-offs:

• Fixed window vs sliding window: Fixed is simpler, sliding is more accurate
• In-memory vs distributed: In-memory is faster, distributed is consistent
• Strict vs graceful degradation: Strict blocks all excess, graceful allows some

Common Mistakes:

• Not handling distributed state
• Ignoring rate limit headers (X-RateLimit-Remaining)
• Forgetting about different limits per tier (free vs paid)
• Not considering retry-after headers

12. Design Search Typeahead

Problem: Design a search autocomplete system suggesting queries as users type.

Key Components:

• Trie service — Stores prefix → suggestions mapping
• Ranking service — Scores suggestions by relevance
• Analytics service — Tracks search trends
• Cache service — Caches popular prefix suggestions
• Update service — Refreshes trie with new queries

Architecture:

• Trie stored in memory for fast prefix lookup
• Suggestions ranked by popularity, recency, and personalization
• Cache layer (Redis) for hot prefixes
• Background job updates trie with trending queries
• Client debounces input (300ms) before requesting suggestions

Scaling Challenges:

• Trie size (billions of possible prefixes)
• Freshness of suggestions
• Personalization (different suggestions per user)
• Multi-language support

Trade-offs:

• Server-side vs client-side trie: Server-side is centralized, client-side reduces latency
• Static vs dynamic ranking: Static is simpler, dynamic adapts to trends
• Global vs per-user cache: Global is efficient, per-user is personalized

Common Mistakes:

• Not handling typos and fuzzy matching
• Ignoring offensive/unsafe suggestions
• Forgetting about mobile keyboard differences
• Not considering result diversity

13. Design Distributed Cache

Problem: Design a distributed caching layer improving read performance.

Key Components:

• Cache service — Stores key-value pairs across nodes
• Consistent hashing service — Distributes keys across nodes
• Eviction service — Removes old entries (LRU, LFU, TTL)
• Replication service — Handles node failures
• Warm-up service — Pre-loads cache on startup

Architecture:

• Consistent hashing distributes keys across cache nodes
• Replication factor of 3 for fault tolerance
• LRU eviction with configurable TTL
• Cache-aside pattern: Application checks cache first, falls back to database
• Monitoring tracks hit ratio and eviction rates

Scaling Challenges:

• Hot keys (popular items hit single node)
• Cache invalidation (keeping cache consistent with database)
• Cold start (warming cache after restart)
• Network partition handling

Trade-offs:

• Cache-aside vs write-through: Cache-aside is simpler, write-through ensures consistency
• Strong vs eventual consistency: Strong is accurate, eventual is faster
• Memory vs disk cache: Memory is faster, disk is cheaper

Common Mistakes:

• Not handling cache stampedes (thundering herd)
• Ignoring cache invalidation strategy
• Forgetting about connection pooling
• Not monitoring hit ratio

14. Design Video Recommendation System

Problem: Design a system recommending videos based on user preferences and behavior.

Key Components:

• Feature service — Extracts user and video features
• Candidate generation service — Generates potential recommendations
• Ranking service — Scores and ranks candidates
• Diversity service — Ensures recommendation variety
• A/B testing service — Tests algorithm variants

Architecture:

• User features: watch history, likes, demographics, time of day
• Video features: category, duration, engagement metrics, freshness
• Candidate generation: collaborative filtering + content-based filtering
• Ranking: ML model (deep learning) scores candidates
• Diversity: Re-rank to ensure variety (not all same category)

Scaling Challenges:

• Real-time personalization (recommendations change with each view)
• Cold start (new users, new videos)
• Scalability (millions of videos, billions of users)
• Freshness (trending videos should surface quickly)

Trade-offs:

• Personalization vs exploration: Personalization shows what you like, exploration discovers new content
• Accuracy vs diversity: Accurate recommendations may be boring, diverse may be less relevant
• Real-time vs batch: Real-time is fresher, batch is cheaper

Common Mistakes:

• Not handling new user cold start
• Ignoring filter bubbles (showing only similar content)
• Forgetting about video freshness
• Not considering negative feedback (dislikes, "not interested")

15. Design Payment System

Problem: Design a payment system handling transactions between users.

Key Components:

• Payment service — Processes payments and refunds
• Ledger service — Maintains transaction records
• Fraud detection service — Identifies suspicious transactions
• Notification service — Sends payment confirmations
• Reconciliation service — Matches internal records with bank statements

Architecture:

• Payment flow: User initiates → Fraud check → Payment processor → Ledger update → Notification
• Idempotency keys prevent duplicate charges
• Two-phase commit for atomicity (deduct sender, credit receiver)
• Saga pattern for distributed transactions
• PCI compliance for card data handling

Scaling Challenges:

• High throughput (thousands of transactions/second)
• Consistency (no double charges or lost money)
• Fraud detection in real-time
• International payments (multiple currencies, regulations)

Trade-offs:

• Synchronous vs asynchronous: Synchronous is simpler, asynchronous is more resilient
• Strong vs eventual consistency: Strong is accurate, eventual is faster
• Centralized vs decentralized ledger: Centralized is simpler, decentralized is more resilient

Common Mistakes:

• Not handling idempotency
• Ignoring race conditions (concurrent transactions)
• Forgetting about refund and dispute handling
• Not considering regulatory compliance (PCI, KYC)

Architecture Code Examples

Rate Limiter (Token Bucket)

import time
import threading

class TokenBucket:
    def __init__(self, capacity, refill_rate):
        self.capacity = capacity
        self.tokens = capacity
        self.refill_rate = refill_rate  # tokens per second
        self.last_refill = time.time()
        self.lock = threading.Lock()
    
    def consume(self, tokens=1):
        with self.lock:
            self._refill()
            if self.tokens >= tokens:
                self.tokens -= tokens
                return True
            return False
    
    def _refill(self):
        now = time.time()
        elapsed = now - self.last_refill
        new_tokens = elapsed * self.refill_rate
        self.tokens = min(self.capacity, self.tokens + new_tokens)
        self.last_refill = now


class DistributedRateLimiter:
    def __init__(self, redis_client, capacity, refill_rate, window):
        self.redis = redis_client
        self.capacity = capacity
        self.refill_rate = refill_rate
        self.window = window
    
    def is_allowed(self, user_id, endpoint):
        key = f"rate:{user_id}:{endpoint}"
        
        lua_script = """
        local key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local refill_rate = tonumber(ARGV[2])
        local now = tonumber(ARGV[3])
        local requested = tonumber(ARGV[4])
        
        local bucket = redis.call('hmget', key, 'tokens', 'last_refill')
        local tokens = tonumber(bucket[1]) or capacity
        local last_refill = tonumber(bucket[2]) or now
        
        local elapsed = now - last_refill
        local new_tokens = math.min(capacity, tokens + elapsed * refill_rate)
        
        if new_tokens >= requested then
            new_tokens = new_tokens - requested
            redis.call('hmset', key, 'tokens', new_tokens, 'last_refill', now)
            redis.call('expire', key, capacity / refill_rate * 2)
            return 1
        end
        
        redis.call('hmset', key, 'tokens', new_tokens, 'last_refill', now)
        return 0
        """
        
        result = self.redis.eval(
            lua_script, 1, key,
            self.capacity, self.refill_rate, time.time(), 1
        )
        return result == 1

News Feed Fan-out Service

from collections import defaultdict
import heapq

class NewsFeedService:
    def __init__(self, user_service, post_service, cache):
        self.user_service = user_service
        self.post_service = post_service
        self.cache = cache
        self.CELEBRITY_THRESHOLD = 10000
    
    def get_feed(self, user_id, cursor=None, limit=20):
        cache_key = f"feed:{user_id}"
        cached_feed = self.cache.get(cache_key)
        
        if cached_feed:
            return self._paginate(cached_feed, cursor, limit)
        
        feed = self._generate_feed(user_id)
        self.cache.set(cache_key, feed, ttl=300)
        return self._paginate(feed, cursor, limit)
    
    def _generate_feed(self, user_id):
        following = self.user_service.get_following(user_id)
        posts = []
        
        for followee_id in following:
            if self._is_celebrity(followee_id):
                posts.extend(self._pull_posts(followee_id, limit=10))
            else:
                posts.extend(self._get_cached_posts(followee_id))
        
        return self._rank_posts(posts, user_id)
    
    def _is_celebrity(self, user_id):
        follower_count = self.user_service.get_follower_count(user_id)
        return follower_count > self.CELEBRITY_THRESHOLD
    
    def _pull_posts(self, user_id, limit=10):
        return self.post_service.get_recent_posts(user_id, limit)
    
    def _get_cached_posts(self, user_id):
        cache_key = f"user_posts:{user_id}"
        return self.cache.get(cache_key) or []
    
    def fan_out(self, post):
        author = post.author_id
        followers = self.user_service.get_followers(author)
        
        if self._is_celebrity(author):
            self.post_service.store_post(post)
            return
        
        for follower_id in followers:
            cache_key = f"feed:{follower_id}"
            self.cache.lpush(cache_key, post.id)
            self.cache.ltrim(cache_key, 0, 499)
    
    def _rank_posts(self, posts, user_id):
        scored = []
        for post in posts:
            score = self._calculate_score(post, user_id)
            heapq.heappush(scored, (-score, post.id, post))
        
        ranked = []
        while scored and len(ranked) < 50:
            _, _, post = heapq.heappop(scored)
            ranked.append(post)
        return ranked
    
    def _calculate_score(self, post, user_id):
        recency = self._recency_score(post.created_at)
        affinity = self._affinity_score(post.author_id, user_id)
        engagement = self._engagement_score(post)
        return 0.4 * recency + 0.3 * affinity + 0.3 * engagement
    
    def _paginate(self, feed, cursor, limit):
        if cursor:
            start = next(
                (i for i, p in enumerate(feed) if p.id == cursor), 0
            )
        else:
            start = 0
        return feed[start:start + limit]

Search Typeahead Service

class TrieNode:
    def __init__(self):
        self.children = {}
        self.is_end = False
        self.frequency = 0
        self.suggestions = []


class TypeaheadService:
    def __init__(self):
        self.root = TrieNode()
        self.cache = {}
    
    def insert(self, query, frequency=1):
        node = self.root
        for char in query.lower():
            if char not in node.children:
                node.children[char] = TrieNode()
            node = node.children[char]
        node.is_end = True
        node.frequency += frequency
        self._update_suggestions(node, query.lower())
    
    def search(self, prefix, limit=10):
        cache_key = f"typeahead:{prefix}:{limit}"
        if cache_key in self.cache:
            return self.cache[cache_key]
        
        node = self.root
        for char in prefix.lower():
            if char not in node.children:
                return []
            node = node.children[char]
        
        suggestions = node.suggestions[:limit]
        self.cache[cache_key] = suggestions
        return suggestions
    
    def _update_suggestions(self, node, query):
        new_entry = (query, node.frequency)
        suggestions = node.suggestions
        
        if new_entry not in suggestions:
            suggestions.append(new_entry)
        
        suggestions.sort(key=lambda x: -x[1])
        node.suggestions = suggestions[:10]
    
    def remove(self, query):
        node = self.root
        for char in query.lower():
            if char not in node.children:
                return False
            node = node.children[char]
        
        if not node.is_end:
            return False
        
        node.frequency = 0
        node.is_end = False
        node.suggestions = [
            (q, f) for q, f in node.suggestions if q != query.lower()
        ]
        return True

Distributed Cache with Consistent Hashing

import hashlib
import bisect

class ConsistentHash:
    def __init__(self, nodes=None, virtual_nodes=150):
        self.virtual_nodes = virtual_nodes
        self.ring = []
        self.node_map = {}
        
        if nodes:
            for node in nodes:
                self.add_node(node)
    
    def add_node(self, node):
        for i in range(self.virtual_nodes):
            key = self._hash(f"{node}:{i}")
            bisect.insort(self.ring, key)
            self.node_map[key] = node
    
    def remove_node(self, node):
        for i in range(self.virtual_nodes):
            key = self._hash(f"{node}:{i}")
            self.ring.remove(key)
            del self.node_map[key]
    
    def get_node(self, key):
        if not self.ring:
            return None
        hash_val = self._hash(key)
        idx = bisect.bisect_right(self.ring, hash_val)
        if idx == len(self.ring):
            idx = 0
        return self.node_map[self.ring[idx]]
    
    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)


class DistributedCache:
    def __init__(self, nodes, max_size=1000):
        self.hash_ring = ConsistentHash(nodes)
        self.caches = {node: {} for node in nodes}
        self.max_size = max_size
    
    def get(self, key):
        node = self.hash_ring.get_node(key)
        cache = self.caches[node]
        
        if key in cache:
            value, expiry = cache[key]
            if expiry is None or time.time() < expiry:
                return value
            del cache[key]
        return None
    
    def set(self, key, value, ttl=None):
        node = self.hash_ring.get_node(key)
        cache = self.caches[node]
        
        if len(cache) >= self.max_size:
            self._evict(node)
        
        expiry = time.time() + ttl if ttl else None
        cache[key] = (value, expiry)
    
    def _evict(self, node):
        cache = self.caches[node]
        if cache:
            oldest_key = min(cache, key=lambda k: cache[k][1] or float('inf'))
            del cache[oldest_key]

Meta System Design Scorecard

Meta interviewers use this scorecard to evaluate system design candidates:

Scoring scale:

• Strong Hire: Exceeds expectations in 3+ criteria
• Hire: Meets expectations in all criteria
• Lean No Hire: Misses 1-2 criteria significantly
• No Hire: Misses 3+ criteria or fundamental misunderstandings

"Meta interviewers specifically look for candidates who can navigate trade-offs. A design without trade-offs is either trivial or wrong."

Minute-by-Minute Walkthrough

Here's how to structure your 45-minute system design round at Meta:

Minutes 1-2: Problem Statement

• Read the problem carefully
• Ask clarifying questions
• Confirm the problem you're solving

Minutes 3-7: Requirements & Scope

• Functional requirements (what the system does)
• Non-functional requirements (scale, latency, availability)
• Constraints and assumptions
• Tip: Write these down on the whiteboard

Minutes 8-18: High-Level Design

• Draw the major components
• Show data flow between components
• Identify APIs and data models
• Tip: Start simple, add complexity later

Minutes 19-23: API & Data Model

• Define key APIs (CRUD operations)
• Design the data schema
• Choose the right database (SQL vs NoSQL)
• Tip: Justify your database choice

Minutes 24-39: Deep Dive

• Pick 1-2 components to go deep on
• Discuss scaling strategies
• Address bottlenecks
• Tip: This is where you differentiate yourself

Minutes 40-44: Trade-offs & Bottlenecks

• Acknowledge limitations
• Compare alternative approaches
• Discuss monitoring and failure handling
• Tip: Be honest about what you don't know

Minutes 45: Wrap-up

• Summarize your design
• Mention what you'd do differently with more time
• Ask the interviewer if they have questions

Meta E4 vs E5 vs E6 System Design Expectations

E4 Tips:

• Focus on getting the basics right
• Don't over-engineer — simple and correct beats complex
• Show you can break down problems

E5 Tips:

• Demonstrate depth in at least one area
• Proactively discuss trade-offs
• Show awareness of operational concerns (monitoring, debugging)

E6 Tips:

• Think about organizational impact
• Consider how the system evolves over 2-3 years
• Discuss team structure and ownership boundaries

Preparation Strategy

1. Master the Fundamentals (Week 1-2)

• Study distributed systems concepts (CAP theorem, consensus, replication)
• Understand databases (SQL, NoSQL, NewSQL) and when to use each
• Learn caching strategies (Redis, Memcached)
• Study message queues (Kafka, RabbitMQ)

2. Practice Common Patterns (Week 3-4)

• News feed (fan-out, ranking)
• Chat system (WebSocket, message ordering)
• Search (trie, Elasticsearch)
• Rate limiting (token bucket, sliding window)
• Distributed cache (consistent hashing)

3. Build a Framework (Week 5-6)

• Create a template for system design interviews
• Practice structuring your thoughts in 45 minutes
• Record yourself explaining designs
• Get feedback from peers or mentors

4. Mock Interviews (Week 7-8)

• Practice with real interviewers
• Get feedback on communication and depth
• Identify weak areas and improve
• Build confidence under pressure

5. Review and Refine (Week 9-10)

• Review past designs and improve
• Study Meta-specific patterns (news feed, messenger, live streaming)
• Practice time management
• Stay calm and structured during the actual interview

"The best system design candidates don't just know the answers — they know how to think through problems they've never seen before."

Why Mock Interviews Matter

Most engineers prepare for Meta by reading blog posts and watching videos. That's like learning to swim by reading a book.

You need to simulate the real experience:

• Pressure — Time constraints, someone watching you think out loud
• Feedback — Identify blind spots you can't see yourself
• Communication — Practice explaining your thought process clearly
• Realism — AI interviewers that push back on your choices, ask follow-ups, and force you to defend your architecture

This is exactly what InterviewSkool provides.

How InterviewSkool Mock Interviews Help

For System Design Rounds:

• AI interviewer presents real Meta-style problems
• You design on a whiteboard while the interviewer watches
• Instant feedback on structure, trade-offs, and scalability
• Detailed scorecard showing where you excel and where you need work

After Every Interview:

• Detailed feedback on strengths and weaknesses
• Overall score and hiring signal
• Areas to improve before the real thing
• Comparison to Meta's actual scorecard criteria

Frequently Asked Questions

How long is the Meta system design interview?

The Meta system design interview is 45 minutes. You get one problem and are expected to cover requirements, high-level design, deep dive, and trade-offs within that time.

What's the difference between E4 and E5 system design at Meta?

E4 focuses on functional design and basic scalability. E5 requires deeper technical knowledge, detailed trade-off analysis, and awareness of operational concerns like monitoring and debugging.

How many system design problems should I practice?

Practice 10-15 common system design problems. Focus on understanding patterns rather than memorizing solutions. The goal is to apply patterns to new problems.

Should I code during the system design interview?

No. System design is about architecture, not implementation. Draw diagrams, explain components, and discuss trade-offs. Don't write code unless specifically asked.

What if I don't know the answer to a follow-up question?

Be honest. Say "I'm not sure, but here's how I'd think about it..." Then walk through your reasoning. Interviewers respect intellectual honesty over fake confidence.

Can I practice Meta-style mock interviews online?

Yes. InterviewSkool offers AI-powered mock interviews that simulate real Meta rounds. Practice system design, coding, and behavioral questions with instant feedback.

Conclusion

Meta system design interviews test your ability to think through complex distributed systems. Focus on structure (requirements → design → deep dive → trade-offs), practice common patterns, and get realistic feedback through mock interviews.

The 15 questions in this guide represent the most common system design problems at Meta. Master these patterns, and you'll be well-prepared for any system design question thrown at you.

Ready to practice? Start your mock interview at InterviewSkool.