0) Problem Restatement
Many interviews (JPMorgan, Visa and others) include a round where you explain a real project you built: what it does, how data flows from the trigger to the output, what each component owns, how failures are handled, and what you personally did. A common follow-up (asked at Visa for a Staff role): "Now imagine it has to work at the scale of Facebook or Google. Redesign it."
This page gives a structure for that answer, and a worked example of scaling a typical project.
Asked at: JPMorgan, Visa — 2 candidate reports between May 2026 and Aug 2026.1) A Simple Structure (10–15 minutes)
- Context (1 min): the business problem, the users, and the rough scale (requests/sec, data size).
- Architecture (3–4 min): draw the boxes: clients, API layer, services, databases, queues, external systems. Follow one request from start to end.
- Data (2 min): what is stored where, who owns it, the key tables or schemas, and consistency needs.
- Hard parts (3 min): one or two problems you actually solved (a race condition, a slow query, an outage). Say what you tried, what worked, and the numbers before and after.
- Operations (1–2 min): how you deploy, monitor and get alerted, and how you handle failures.
- Your role and reflection (1 min): what you owned, and what you'd change now.
Tips:
- Use real numbers ("p99 went from 900 ms to 120 ms").
- Say "I" for your work and "we" for the team, and be clear which is which.
- Prepare for "why not X?" questions on each choice.
2) Example Project (Before Scaling)
An internal order notification service: when an order ships, it sends an email and SMS to the customer.
Architecture Diagram
flowchart LR
OS["Order Service"] -->|"REST call"| NS["Notification Service"]
NS --> DB[("Postgres - templates, logs")]
NS --> EM["Email provider"]
NS --> SMS["SMS provider"]- Scale today: 50K notifications/day, one region, 2 app instances, one Postgres.
- A hard part solved: the SMS provider sometimes timed out, so orders waited and sometimes got 2 texts. Fix: added timeouts, an idempotency key per (order, channel), and moved sending to a background worker.
3) Redesign for Planet Scale
Assume 100x–1000x traffic: 50M notifications/day across many regions, with spikes (sales events). Walk through what breaks first, then fix it:
| What breaks | Why | Fix |
|---|---|---|
| Synchronous REST call from Order Service | Slow providers block orders, spikes overload us | Publish an "order shipped" event to Kafka. Notification consumers process it asynchronously |
| Single Postgres | Write volume and single point of failure | Shard the notification log by user ID. Keep templates in a small replicated DB plus cache. Primary + replicas per shard |
| One region | Latency for global users, region outage = no notifications | Multi-region deployment. Events processed in the user's home region. Replicate critical data |
| Providers' rate limits | Spikes exceed provider quotas | Per-provider rate limiters, priority queues (transactional before marketing), multiple providers with failover |
| Duplicate sends on retries | At-least-once processing | Idempotency key (event_id, channel) stored with a TTL. Check before sending |
| No visibility | Hard to debug at scale | Metrics per channel and provider, tracing by event ID, dead-letter queue with alerts |
3.1 Redesigned Architecture
Architecture Diagram
flowchart LR
OS["Order Service"] -->|"OrderShipped event"| K[("Kafka - partitioned by user")]
K --> W["Notification workers - per region"]
W --> ID[("Idempotency store")]
W --> PREF[("User prefs + templates cache")]
W --> RL["Per-provider rate limiter"]
RL --> P1["Email providers"]
RL --> P2["SMS providers"]
W -->|"failed after retries"| DLQ[("Dead-letter queue")]
W --> LOG[("Sharded delivery log")]3.2 Talking points that show depth
- Consistency: notifications can be eventually consistent. The order DB stays strongly consistent. Say this out loud.
- Replication (the key discussion at Visa): explain leader-follower replication, synchronous vs asynchronous replication (data loss vs latency), and how failover works.
- Cost: SMS is expensive, so batch and deduplicate, respect user preferences, and prefer push notifications when possible.
- Rollout: move from sync to async gradually. Dual-run for a week and compare delivery counts before switching off the old path.
4) Common Follow-up Questions
- "What would you do differently?" Pick something real, like "I'd have made it event-driven from day one" or "I'd add load tests before launch".
- "How did you know it worked?" Metrics, dashboards, alerts and the before/after numbers.
- "What if the database is down?" Explain failover, what users see during it, and how data is protected (backups, point-in-time recovery).
5) Wrap-Up
Present your project in a fixed order: context and scale, the boxes and one request's path, data ownership, one or two hard problems with numbers, operations, and your role. To scale it to planet size, name what breaks first and fix it step by step: make it async with events, shard and replicate data, go multi-region, respect provider limits, add idempotency, and build observability, while being honest about the trade-offs.