Red flags checklist: 20 self-assessment checks before finishing
The 20 most common design gaps that interviewers notice and candidates miss. Run through this checklist mentally before wrapping up to catch the problems that silently cost you points.
Why Self-Review Matters
Interviewers rarely tell you when your design has a fatal flaw — they may note it and factor it into evaluation, but they often don't interrupt to correct you. Catching problems yourself, before the end, signals that you can evaluate your own designs critically.
Use this as a mental checklist in the last 3-5 minutes of your session. You won't have time to address all 20, but spotting and verbally acknowledging a gap is far better than leaving it unaddressed.
Checklist
Requirements and Scope
1. Did you confirm write vs. read ratio? A read-heavy system (10:1) gets a different architecture than a write-heavy one (1:10). If you didn't ask, assuming equal distribution may mean a wrong design.
2. Did you scope the problem explicitly? Saying "I'm not covering search or notifications to focus on the core read/write path" shows judgment. Leaving large feature areas completely unmentioned looks like oversight.
3. Did you handle the most common user action, not just the most interesting one? System design interviews often involve a common boring path (load the inbox) and an interesting complex path (send a message to 50M followers). Make sure the boring path works.
Scale and Estimation
4. Did your scale estimates drive any design choices? If you estimated 100M users and then designed a single-node system, either the estimate or the design is wrong.
5. Is your storage estimate reasonable? Sanity check: if each user generates 1MB/day and you have 100M users, that's 100TB/day. Does your design handle that?
6. Did you account for traffic spikes? Daily active users gives you average load. Peaks can be 5-10x the average (Monday morning, event launches, viral posts). Average load design may fail under peaks.
Data Model
7. Can you reconstruct user state from your data model? If the system crashed and restarted, could you rebuild the current state from your database? If not, there's a missing write path or storage gap.
8. Does your schema support your main query patterns without a full table scan? If reading a user's feed requires scanning 10M rows, you need a denormalized feed table, a covering index, or a different data model.
9. Did you consider schema evolution? New features will add fields. Does your design allow adding a column without a full-table rewrite at 1B rows?
Architecture
10. Is there a single point of failure? Any component that has no redundancy is a single point of failure. Load balancer, database primary, message queue — all should have failover.
11. Are all your caches cacheable? Mutable user-specific data is hard to cache. Check that each cache layer is caching actually-cacheable content (static or low-update-frequency data per user).
12. Did you design for the unhappy path? What happens when the downstream service is unavailable? What happens when a message fails? Without retry + dead-letter queue, silent drops are common.
13. Does your queue consumer create duplicates? At-least-once delivery means your consumer may process a message twice. Is your consumer idempotent?
14. How does data get deleted? User deactivations, content moderation, GDPR right-to-erasure — each requires a delete propagation strategy. Have you accounted for this?
Consistency and Correctness
15. Could two nodes claim to be doing the same work simultaneously? Scheduled jobs, queue workers, and leader-elect tasks need coordination mechanisms to avoid duplicate execution.
16. Is there a race condition on your critical write path? Two users simultaneously claiming the last seat, two processes writing to the same row — does your design serialize these correctly?
17. Does your cache get invalidated correctly? Cache-aside without invalidation on writes gives users stale data. Is there a path that updates the cache or evicts the stale entry when the underlying data changes?
Operations and Observability
18. How would you know if this is broken in production? What metrics would you alert on? If you can't name at least one "this is broken" signal (error rate, queue depth, latency p99), your design has an observability gap.
19. Can you deploy this without downtime? A design that requires a stop-the-world schema migration to each feature is operationally painful. Note if your design requires downtime and how you'd approach zero-downtime deployment.
20. What's the first thing that breaks at 10x load? Identify the bottleneck. If you can't, that's the gap to address. Every design has a bottleneck; the best designs know where it is.
How to Use This Checklist
You don't need to address all 20 out loud. Pick the ones most relevant to the specific system you designed and verbally acknowledge them:
"One thing I haven't addressed is cache invalidation — when a user updates their profile, the profile cache isn't invalidated in my current design. I'd handle that by having the profile service emit a cache eviction event on any profile write."
This is more valuable than rushing through 10 items without substance. Depth on 3 relevant flags beats breadth on 20 surface mentions.
Quick Recap
- Self-assessment before finishing catches gaps that interviewers notice but don't always interrupt to correct you on. Acknowledging a gap yourself signals critical thinking; leaving it unaddressed looks like oversight.
- Requirements gaps (missing write/read ratio, unscoped problem areas, missing common paths) are often the most damaging because they may mean the architecture is wrong for the actual problem.
- Architecture gaps to check: single points of failure, caches that are actually uncacheable (mutable per-user data), queue consumers that create duplicates, and missing delete propagation.
- Consistency errors are subtle: simultaneous writes claiming the same resource, race conditions on critical paths, and cache staleness after writes are the most common types.
- The "what breaks at 10x" question is almost always asked by the interviewer. Having the answer ready — and being able to name the bottleneck — is the difference between a candidate who designed a system and one who understands the system they designed.