FAANG system design interviews follow a predictable rubric. The differentiator between a 'Hire' and a 'No Hire' is usually not the architecture you draw — it is the specific scale numbers you cite, the trade-offs you name explicitly, and the failure modes you address. This cheat sheet collects the exact anchors strong candidates use at Google, Meta, Amazon, and Microsoft.
Scale Anchors by Company
Google scale
Google Search: 8.5B queries/day. YouTube: 2.5B MAU, 500h of video uploaded per minute. Gmail: 1.8B users. When asked to design a Google system, anchor on these numbers from sentence one. State your QPS assumption (e.g. '100K QPS at peak'), data volume (PB-scale), and read:write ratio (typically 100:1 for search, 1:10 for video upload).
Meta scale
Facebook: 3B MAU. Instagram: 2.4B MAU. WhatsApp: 2.9B MAU. NewsFeed serves ~1B users with hundreds of feed items each — fan-out is the dominant scale story. Meta system design interviews assume distributed-cache + sharded-database + write-fan-out as the default architecture.
Amazon scale
amazon.com: 300M+ active customers, 12M+ products. AWS S3: 280 trillion objects. Amazon system design interviews lean toward service-oriented architecture with explicit service boundaries, eventual-consistency trade-offs, and queue-based decoupling (SQS, Kinesis).
Microsoft scale
Microsoft Teams: 320M MAU. Azure: thousands of regions. Microsoft system design uses Azure-native primitives — Cosmos DB (multi-master), Service Fabric (stateful services), AKS, Service Bus, Front Door. Frame answers in Azure terminology, not generic AWS.
Universal Data Structure Cheat Sheet
Load balancer placement
Mention L4 vs L7 explicitly. Round-robin is fine for stateless services; sticky session-based hashing for stateful. Health check interval (typically 10s) and failure threshold (3 consecutive). Read about Envoy / nginx / ALB depending on company.
Cache strategy
Read-through (cache populated on miss), write-through (cache + DB written together), write-back (cache first, DB async). State your TTL choice (typically 5-60 minutes). Mention cache invalidation explicitly — it is the hard part. Redis vs Memcached: Redis if you need data structures, Memcached if pure key-value at scale.
Database choice
Relational (Postgres, MySQL) for transactional consistency. Document (MongoDB, DynamoDB) for flexible schema. Key-value (Cassandra, DynamoDB) for write-heavy. Time-series (InfluxDB, TimescaleDB) for metrics. Wide-column (HBase, Cassandra) for sparse data. Justify your choice based on read:write ratio and consistency needs.
Queue + stream
Kafka for high-throughput ordered streams (millions of events/sec). RabbitMQ for traditional pub-sub. SQS for AWS-native queues. Mention consumer-group parallelism, partition strategy, and at-least-once vs exactly-once delivery.
CDN + edge
CloudFront, Cloudflare, Akamai. Cache static assets (images, JS, CSS) at edge — 100ms-tier latency to global users. Mention cache invalidation strategy (purge on deploy, versioned URLs).
Trade-Off Vocabulary Interviewers Listen For
- CAP theorem: pick 2 of Consistency, Availability, Partition tolerance. Most distributed systems pick AP with eventual consistency.
- Strong consistency vs eventual consistency: name the specific consistency model you chose (linearizable, sequential, causal, eventual).
- Latency vs throughput: every system has a hard trade-off — name yours.
- Cost vs performance: cite specific cloud costs ($0.023/GB-month S3, $0.10/M API Gateway) when relevant.
- Read-heavy vs write-heavy: state your read:write ratio explicitly.
- Hot partition: how do you avoid one user / one celebrity creating a hot shard? Sharding key choice matters.
InterviewLift's mock interview includes system-design mode with the Meta-scale and Google-scale anchors pre-loaded. The real-time copilot surfaces these trade-offs in your overlay during the actual interview so you never miss a rubric-axis.
Reviewed by the InterviewLift customer-success team, who prepare candidates for real interviews every week.
Try Jarvis free: 15 questions
No card needed. Use it in your next practice round or interview.