Top System Design and Architecture Questions Asked in Senior Developer Interviews

What interviewers are evaluating

• Can you turn ambiguity into explicit requirements?
• Can you choose appropriate boundaries and data ownership?
• Do you reason about scale instead of adding technology by habit?
• Can you explain consistency, reliability and security trade-offs?
• Do you design for operations: metrics, alerts, rollout and recovery?
• Can you adapt when the interviewer changes a constraint?

1. Design a high-traffic API behind load balancers

Discuss request distribution, health checks, connection handling, zones, stateless application instances and overload protection. Strong candidates ask whether sessions exist, define timeouts and explain what happens when a zone or downstream dependency fails.

2. Design caching for a read-heavy product catalogue

Cover cache-aside versus write-through, key design, TTL, invalidation, hot keys, stampedes and stale-data tolerance. The question is not “Should we use Redis?” but “Which data may be stale, for how long, and how do we protect the database during misses?”

3. Choose a database for orders and search

Separate transactional requirements from search access patterns. Explain schemas, indexes, transactions and why a search index may be a derived view rather than the source of truth. Include reconciliation when updates to derived systems lag or fail.

4. Shard a rapidly growing dataset

Define the shard key and show how it affects routing, hotspots, resharding and cross-shard queries. Interviewers want to see the cost of sharding, not only its capacity benefit. Consider tenant, geography, hash and time-based choices.

5. Design replication and failover

Explain synchronous versus asynchronous replication, read replicas, lag, failover detection, split brain and recovery-point expectations. State which writes can be lost and how clients behave during leader changes.

6. Build a queue-backed notification service

Cover producer acknowledgement, partitioning, consumer scaling, retries, dead-letter handling, ordering and idempotency. “Exactly once” should trigger careful scoping; end-to-end effects often require idempotent consumers and deduplication rather than a slogan.

7. Split a monolith into services

Start with business boundaries and data ownership. Discuss migration sequencing, compatibility, observability and operational cost. A senior answer may keep part of the monolith when independent scaling or ownership does not justify a new service.

8. Design rate limiting

Clarify the identity and policy: user, API key, tenant, IP or endpoint. Compare token bucket, leaky bucket and fixed/sliding windows. Address distributed counters, burst tolerance, failure behavior and response headers.

9. Choose a consistency model

Use a concrete operation. Account balances, inventory reservations and social likes need different guarantees. Explain read-after-write, monotonic reads, eventual consistency and conflict handling. Tie the guarantee to user harm and system cost.

10. Add observability to a distributed service

Define user-facing indicators, structured logs, metrics and traces. Explain correlation IDs, sampling, cardinality control and alert ownership. A dashboard is not enough: show how an on-call engineer moves from symptom to dependency and safe mitigation.

11. Handle dependency and region failure

Discuss timeouts, bounded retries with jitter, circuit breaking, load shedding, degraded modes and data recovery. For regional failure, cover traffic steering, replicated state, recovery objectives and the operational process for failover and failback.

A reusable interview structure

1. Clarify functional scope and users.
2. State scale assumptions and critical guarantees.
3. Define APIs and data model.
4. Draw the simplest end-to-end design.
5. Find the likely bottleneck.
6. Deep-dive on two important trade-offs.
7. Add failure handling, observability, security and rollout.
8. Summarize limitations and next evolution.

Build the practice schedule with How to Prepare for Coding and System Design Interviews While Working Full-Time, How to Answer ‘Tell Me About a Project You Worked On’.

Conclusion

A senior design answer is a sequence of justified decisions. Start simple, make assumptions visible and spend time on the parts where the system can lose data, overload dependencies or confuse operators.