Designing a test strategy under pressure
System-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.
How to approach any system-design-for-testing question
You are not being asked to build the system — you are being asked how you would verify it. A reliable structure:
- Clarify scope and scale — users, requests per second, read/write ratio, consistency needs. Numbers drive everything after.
- Map the components — API layer, database, cache, queues, third-party calls. Each is a test surface.
- Apply the test pyramid — unit at the base, then API/contract tests, then a thin layer of end-to-end. State what you would test at each level.
- Cover the non-functional axes — performance (load, stress, spike), security, resilience (what happens when a dependency fails?), and observability (how do you know it broke in production?).
- Name the risks — the single biggest failure mode and how your strategy catches it. This is the senior signal.
15 classic systems and what the interviewer is really evaluating
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 |
Practise the technical rounds
System design sits on top of framework and API skills — drill those first.
Framework Simulator → API Scenario Lab Mock InterviewFrequently asked questions
Do SDETs get system design questions?
Yes, 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.
How do I prepare for system design for testing?
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.
What is the test pyramid?
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.
Which systems come up most?
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.