Before you go — grab our most downloaded resource.
QA cheat sheets used by 30,000+ testers.
🔒 No spam, ever. Join 30,000+ QA engineers. Unsubscribe anytime.
No thanks, I'll skip the free cheat sheetsSystem-design questions now appear in senior SDET loops. Here is a repeatable way to answer them, plus the 15 classic systems and exactly what each panel is judging.
"Design a test strategy for a URL shortener." "How would you test a payment system at scale?" System-design questions have moved from SDE interviews into senior SDET loops, and they are where many strong automation engineers stumble — not because they lack skill, but because they have never rehearsed thinking about a system at the architecture level.
You are not being asked to build the system — you are being asked how you would verify it. A reliable structure:
These are the systems that come up most, the companies that ask them, and what the panel is judging in your answer.
| System to design | Companies that ask | Difficulty | What the interviewer evaluates | Must-know concepts |
|---|---|---|---|---|
| URL Shortener (like bit.ly) | Google, Atlassian, Razorpay, Amazon | Medium | DB schema design, caching strategy, hash collision handling, scalability | Base62 encoding, consistent hashing, Redis TTL, SQL vs NoSQL tradeoff |
| Rate Limiter | Razorpay, PhonePe, CRED, Google | Medium | Algorithm choice (token bucket vs fixed window), distributed rate limiting | Token bucket, sliding window, Redis INCR with TTL, distributed counters |
| Notification Service | Atlassian, Amazon, Flipkart, PhonePe | Medium | Fan-out design, at-least-once delivery, retry with exponential backoff | Kafka topics, dead letter queue, idempotency keys, delivery guarantees |
| Design Twitter/Feed | Google, Amazon, Microsoft | Hard | Fan-out on write vs read, celebrity problem solution, cache invalidation | Push vs pull model, Redis sorted sets, consistent hashing, sharding |
| Design YouTube | Google, Amazon | Hard | Async processing, CDN architecture, database choices, search index | HLS streaming, distributed transcoding, Elasticsearch, content delivery |
| Design Uber/Lyft | Uber, Google, Amazon, Flipkart | Hard | Real-time geolocation, proximity matching, WebSockets, consistency | Geohash, quadtree, WebSockets vs polling, surge pricing algorithm |
| Design WhatsApp/Chat | Amazon, Google, Microsoft, Atlassian | Hard | WebSocket management, message ordering, offline delivery, read receipts | WebSockets, message queues, Cassandra for messages, HBase |
| Design Google Search | Very hard | Crawler politeness, inverted index, ranking algorithms, distributed processing | MapReduce, inverted index, TF-IDF, PageRank, Bloom filter | |
| Design Dropbox/Drive | Google, Amazon, Atlassian | Hard | Chunking strategy, delta sync, conflict resolution, deduplication | Content-addressable storage, rsync algorithm, S3, block storage |
| Design CI/CD Pipeline (like Jenkins) | Atlassian, Microsoft, HashiCorp | Medium-hard | Queue management, worker orchestration, artifact caching, failure handling | Priority queues, Docker containers, artifact versioning, webhook design |
| Design Payment System | Razorpay, PhonePe, CRED, PayPal | Hard | Idempotency, double-spend prevention, ACID transactions, reconciliation | Idempotency keys, distributed transactions, 2-phase commit, saga pattern |
| Design LRU Cache | Amazon, Google, All companies | Easy | Data structure choice, eviction policy, thread safety, distributed cache | LRU vs LFU, Redis eviction policies, concurrent HashMap, read-through cache |
| Design Search Autocomplete | Google, Amazon, Atlassian | Medium | Trie design, ranking algorithm, real-time vs batch updates | Trie, Redis sorted sets, consistent hashing, CDN caching |
| Design Stock Exchange | Groww, CRED, ZERODHA | Hard | Lock-free queues, order matching algorithms, high-frequency throughput | Price-time priority, lock-free data structures, event sourcing |
| Design Distributed Message Queue (Kafka) | All FAANG, Razorpay, Atlassian | Hard | Partition strategy, replication factor, consumer lag, at-least-once delivery | Log-structured storage, Zookeeper, ISR (in-sync replicas), compaction |
System design sits on top of framework and API skills — drill those first.
Framework Simulator → API Scenario Lab Mock InterviewYes, increasingly in senior and product-company loops. The framing is usually "design a test strategy for X" rather than "build X", so you focus on how you would verify the system, not architect it from scratch.
Practise the structure — clarify scale, map components, apply the test pyramid, cover performance/security/resilience, and name the top risk. Rehearse it on five or six classic systems until the structure is automatic.
A model for balancing test types: many fast unit tests at the base, fewer API and contract tests in the middle, and a thin layer of slow end-to-end tests at the top. It keeps suites fast and stable.
URL shorteners, payment systems, notification services, rate limiters, and feed/timeline systems are among the most common. The table above lists fifteen with the companies that ask them.
System-design fundamentals are durable; the specific systems and scale numbers evolve — treat ranges as guidance.