Real Interview SD Questions — 10+ Companies

Source: [[raw/Every System Design Question I Was Asked in Real Interviews at 10+ Companies]] Author: Senior Backend Engineer at Canva. 15+ companies, 10+ SD rounds documented.

Key insight: "Design Twitter" and "Design a URL Shortener" almost never show up in real interviews. Domain-specific, production-flavored problems are the norm at senior levels.

---

Question Bank

---

Deep Dive: Questions Worth Studying

Pagination (N26 — candidate bombed this)

Three levels of depth expected:

Level 1 — LIMIT/OFFSET (avoid in interviews):

SELECT * FROM items ORDER BY id LIMIT 20 OFFSET 10000;
-- Problem: DB scans 10020 rows to return 20. Slow on large tables.

Level 2 — Keyset / Seek pagination (correct answer for SQL):

SELECT * FROM items WHERE id > :last_seen_id ORDER BY id LIMIT 20;
-- O(log N) — uses index directly. No offset scan.

Level 3 — Cursor-based (correct answer for NoSQL / APIs):

GET /posts?cursor=eyJpZCI6MTIzNH0&limit=20
-- Cursor is opaque (base64 encoded last-seen-id or timestamp)
-- Works across NoSQL DBs that don't support OFFSET
-- Used by Twitter, Instagram, GitHub APIs

What kills candidates: Proposing "fetch all, paginate in memory." Instant fail.

Real-Time Chat (WhatsApp) — Failed twice, then mastered

Key components to cover:

• WebSocket connections: persistent bidirectional. Connection routing table (which server holds which user's socket)
• Message queuing: Kafka for reliable delivery. Producer = sender service, consumer = recipient delivery service
• Delivery guarantees: At-least-once + idempotency key (message ID) to deduplicate. Store undelivered msgs for offline users
• Presence tracking: Heartbeat from client every N seconds. Redis key with TTL = online status
• Storage: Cassandra for messages (time-ordered, write-heavy, partition by conversation ID)

See full design: [[System Design/Problem Designs/WhatsApp]]

Saved Search Notification (Talabat)

Problem: User saves search "JavaScript" → daily email digest of new listings matching that search.

Design sketch:

1. Scheduler (cron job) runs daily at 8am
2. For each saved search: query index for items added in last 24hrs matching search
3. Fan-out to email queue per user
4. Email service sends digest

Key questions interviewers probe:

• What if a user has 100 saved searches? (batch query vs per-search)
• What if 1M users all get triggered simultaneously? (rate limit the email service, leaky bucket)
• What if email fails? (DLQ, retry with exponential backoff)

Push Notification for Posts (Mercari) — "No news feed" twist

The constraint "no consolidated feed" forced depth on the notification delivery path specifically:

User A posts
  → Write post to DB
  → Fetch A's follower list (could be millions for influencers)
  → Fan-out: enqueue notification job per follower
  → Notification workers: FCM/APNs/SNS per platform
  → Delivery tracking: ack from device → mark delivered

Hard problems:

• Hot users (celebrities): Follower list is 10M+. Fan-out at write = millions of enqueues per post. Fix: fan-out on read for large followings (hybrid approach)
• Delivery guarantees: Device offline → store notification, retry when online. Exactly-once delivery with idempotency key.

See: [[System Design/Problem Designs/Notification System]]

Subscription Payment System (Canva — got the job)

Core flows to design:

Signup:     user → payment processor (Stripe) → webhook → activate subscription
Renewal:    cron → charge customer → success/fail → update subscription state
Cancellation: user → end-of-period flag → no renewal
Failed payment: retry N times with backoff → dunning flow → cancel

Key concepts:

• Idempotency: Charge endpoint must be idempotent (same request ID = same result, no double charge)
• Subscription states: active → past_due → cancelled → expired
• Webhook reliability: Stripe calls your webhook. Must be idempotent. Return 200 fast, process async.
• Tooling matters: Candidate practiced on Excalidraw but got Google Doc → flow was disrupted. Ask the interviewer for tooling preference upfront.

---

Patterns Across All Interviews

1. Push-Based Systems Come Up Constantly

3 of 10 interviews involved WebSockets, push notifications, or persistent connections.

Must know cold:

• Polling vs long-polling vs SSE vs WebSocket — when to use each
• WebSocket connection routing (which server holds which connection)
• Fan-out patterns: on write (fast read, slow write) vs on read (slow read, fast write)
• Push notification pipeline: FCM/APNs → delivery tracking → retry

2. Seniority Bar Is Real

Foodpanda Staff: "The expectation wasn't to design a system. It was to prove you understand every layer of the stack."

3. Domain-Specific Problems Are Common

Companies ask problems from their own domain. Research the company before interviewing:

• Fintech: payment systems, idempotency, fraud detection
• Delivery: geospatial, routing, real-time GPS tracking
• Marketplace: search, inventory, notification pipelines

4. LLD Catches You Off Guard

Glovo's round = 60min HLD + 30min UML class diagram. Most candidates only prep HLD.

LLD basics to have ready:

• Entity + attribute design for the system
• Relationships: 1:1, 1:N, N:M
• Key operations as methods
• State machines (subscription status, order status)

See: [[System Design/Low Level Design]]

5. Tooling Affects Performance

Candidate practiced Excalidraw, got Google Doc → hurt their flow. Ask in advance: "What tool should I use for the design? Do you prefer a specific format?"

---

For Your Prep

Problems NOT on your current radar that appeared in real interviews:

Key gap identified: LLD (UML class diagram phase). Exposed repeatedly at senior rounds. See W06+ plan in [[synthesis/Interview Prep Hub]].

---

Related

• [[System Design/Senior SD Mindset]] — L7 mindset (failure-first, cost every component)
• [[System Design/Problem Designs/WhatsApp]] — real-time chat full design
• [[System Design/Problem Designs/Notification System]] — push notification pipeline
• [[API Design Principles]] — pagination, idempotency, REST
• [[System Design/Low Level Design]] — LLD patterns, SOLID, class design
• [[synthesis/Interview Prep Hub]] — SD checklist + preparation formula