Wrap-Up (Step 5 Deep Dive)
Time Budget: 5 minutes — The final act. Leave a lasting impression by showing system thinking beyond the immediate design.
The Wrap-Up is your closing argument. You've built the system — now you demonstrate that you think like a senior engineer: someone who considers failure, operational concerns, future growth, and the limits of what you've built.
Why It Matters
Most candidates stop when the architecture is drawn. The Wrap-Up is your chance to stand out:
- Operational maturity — You think about how a system lives in production, not just how it's built on paper.
- Self-awareness — You know the limitations of your own design and can articulate them.
- Long-term thinking — You can anticipate what breaks at 10x traffic before it happens.
- Curiosity — Asking thoughtful questions about their real system signals genuine interest and intelligence.
The Wrap-Up Flow
Component 1 — Summarize the Design (2 mins)
The Formula
"We built a [system name] that handles [scale]. The three key design decisions were [1], [2], and [3]. The system achieves [non-functional requirements] through [mechanisms]."
What to Include vs. Skip
Worked Script — URL Shortener
"Let me quickly summarize what we designed.
We built a URL Shortener handling 1,200 writes/sec and 116,000 redirects/sec — a 100:1 read-heavy system.
Our three most important decisions:
First, we chose Cassandra over MySQL because our 182 TB storage need and key-value access pattern make it the natural fit — sharding by
short_codegives even distribution with no hotspots.Second, we put Redis cache (10 GB, LRU) in front of Cassandra, absorbing 95% of redirect traffic and reducing Cassandra load from 116K to just ~6K reads/sec.
Third, we used Snowflake ID + Base62 encoding for collision-free short code generation across all app servers — 62⁷ gives us 3.5 trillion unique codes, ~92 years of runway.
The system hits 99.99% availability through Redis Sentinel, Cassandra RF=3 quorum, and auto-scaling across 3 AZs."
Component 2 — Call Out Remaining Risks (1 min)
The Risk Quadrant
Categorize the risks you're aware of but didn't fully solve:
How to Present a Risk (Script)
"One risk I want to flag that we didn't fully resolve: hotspot short codes. If a URL goes viral — say, a tweet from a celebrity with 50 million followers — 100% of traffic hits a single Cassandra shard. Our Redis cache handles most of it, but the cache miss storm on cold start could still overwhelm that shard.
To fix this properly, I'd add a local in-process L1 cache (e.g., a simple LRU map on each app server) for the top 1,000 URLs. That prevents even a Redis round-trip for the hottest content."
The Risk Presentation Template
Component 3 — Propose Future Improvements (1 min)
Link every improvement to a specific scale trigger. Never say "we could improve X" — say "when we hit Y traffic, we'd need X because Z".
Scale Roadmap: 1x → 10x → 100x
The Improvement Script
"If our traffic grew 10x to 1 million redirects/sec, the first thing I'd tackle is multi-region active-active deployment. Right now we're single-region, so a us-east-1 outage takes the whole system down. At 10x, the business impact justifies the complexity of cross-region replication.
At 100x — 10 million redirects/sec — I'd investigate pre-signed CDN URLs for the top million short codes, so redirects happen entirely at the edge with zero origin server hits. That's the endgame for a redirect-heavy system."
Component 4 — Ask Meaningful Questions (1 min)
This turns a test into a conversation. The best candidates leave the interviewer thinking "I'd like to work with this person."
Question Categories
Worked Questions — URL Shortener Context
✅ GREAT QUESTION (system-specific):
"I chose eventual consistency for redirects in this design.
Does [Company]'s real URL shortening service make the same
trade-off, or did you find a use case that required stronger
consistency guarantees?"
✅ GREAT QUESTION (about scale surprises):
"We estimated a 100:1 read-to-write ratio. Was the actual
ratio in production what the team expected, or did usage
patterns surprise you?"
✅ GREAT QUESTION (about evolution):
"At what point did the team decide to move from a SQL
database to a distributed store, and what triggered that
migration?"
❌ WEAK QUESTION (too generic):
"What's it like working at [Company]?"
❌ WEAK QUESTION (already answered):
"Should I have used MySQL instead of Cassandra?"The Complete Interview Dialogue (URL Shortener)
A beat-by-beat example of how the Wrap-Up sounds in a real interview:
The Complete System — Final Architecture Snapshot
The system as it stands after all 5 steps:
Interviewer Scoring Rubric
Understanding how interviewers score the Wrap-Up phase:
| Dimension | Below Bar | Meets Bar | Exceeds Bar |
|---|---|---|---|
| Summary | Skips it or just says "we're done" | Restates components | Top 3 decisions + NFR achievement in 60 seconds |
| Risk Awareness | Claims design is complete | Notes 1 obvious risk | 2-3 risks with mitigations and priorities |
| Future Thinking | No improvement ideas | Generic "add more servers" | Scale-triggered roadmap (1x → 10x → 100x) |
| Questions | No questions | Generic questions about the company | System-specific questions that show deep engagement |
| Overall Tone | Defensive or rushed | Professional | Collaborative — feels like working with a colleague |
The Complete Interview Journey — All 5 Steps
Red Flags vs. Green Flags
| 🔴 Red Flag | 🟢 Green Flag |
|---|---|
| "That's the design, any questions?" | Deliver a crisp 60-second structured summary |
| Pretend the design is complete and perfect | Proactively surface 2-3 remaining risks |
| Generic improvements: "add more servers" | Tie improvements to specific traffic thresholds |
| No questions for the interviewer | Ask 1-2 system-specific, thoughtful questions |
| Ask about salary or perks at this stage | Ask about real technical challenges they faced |
| Summarize every technical detail again | Only hit the top 3 decisions + their rationale |
| Passive tone — waiting to be dismissed | Drive: "Let me summarize and then I have a question for you" |
Final Mindset Checklist
Run through this mentally in the last 60 seconds:
□ Did I clarify requirements before designing?
□ Did I estimate scale and let it drive architecture?
□ Did I define APIs and a data model before drawing boxes?
□ Did I walk through the happy path end-to-end?
□ Did I address 2-3 bottlenecks with explicit trade-off reasoning?
□ Did I identify SPOFs and explain mitigations?
□ Did I summarize in under 2 minutes hitting only the top decisions?
□ Did I name 1-2 remaining risks with mitigations?
□ Did I propose improvements tied to specific scale triggers?
□ Did I ask at least one system-specific question?
□ Did I drive the conversation or wait to be led?
□ Did every design decision connect back to a stated requirement?TIP
The best system design interviews feel like a collaborative design session with a colleague, not a test you're being evaluated on. Drive the conversation, think out loud, and invite feedback as you go.
IMPORTANT
The interviewer does not expect a perfect design. They want to see how you think. A candidate who reasons clearly about a flawed design beats a candidate who presents a polished diagram without explaining the rationale behind it.
NOTE
The Wrap-Up is also your chance to correct yourself gracefully. If the interviewer's questions during the session revealed a flaw in your design, the summary is where you say: "Looking back, I think I'd reconsider [X] because [Y] — a better approach would be [Z]." That kind of intellectual honesty is a strong positive signal.