Whiteboard and Deep Dive a Past Project

Quick Overview

This question evaluates a candidate's end-to-end system design skills, including architecture decomposition, trade-off analysis, data consistency choices, scalability and resiliency patterns, and integration of operational practices for a user-facing distributed service.

Whiteboard and Deep Dive a Past Project

Company: Remitly

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Whiteboard the end-to-end architecture of a past project you led. Explain the major components, data flows, storage choices, and external dependencies. Detail key trade-offs you made (e.g., consistency vs. availability, latency vs. cost), how you handled scaling and failure recovery, and how you tested, monitored, and iterated on the design. Conclude with what you would change if you rebuilt it today.

Overview: This question evaluates a candidate's end-to-end system design skills, including architecture decomposition, trade-off analysis, data consistency choices, scalability and resiliency patterns, and integration of operational practices for a user-facing distributed service.

|Home/System Design/Remitly
Remitly logo
Remitly
Aug 13, 2025
hardSoftware EngineerOnsiteSystem Design
10
0

System Design: End-to-End Architecture Walkthrough

Prompt

Whiteboard the end-to-end architecture of a complex, user-facing system you led. Cover:

  1. Major components and their responsibilities.
  2. Data flows and key interactions (happy-path and failure-path).
  3. Storage choices and data models (including consistency needs).
  4. External dependencies and how you integrated with them.
  5. Key trade-offs (e.g., consistency vs. availability, latency vs. cost).
  6. Scaling strategy and failure recovery/resiliency patterns.
  7. Testing, monitoring/alerting, and iteration practices.
  8. What you would change if you rebuilt it today.

Minimal Context (to keep the exercise concrete)

Assume a high-availability, low-latency service with the following example constraints:

  • p99 latency: ≤ 300 ms for synchronous APIs.
  • Availability: ≥ 99.95%.
  • Peak load: ~2,000 requests/sec (bursty), average ~300 requests/sec.
  • Multi-region read traffic; write traffic primarily in one region initially.
  • Mix of strongly consistent operations (e.g., money movement, ledgers) and eventually consistent operations (e.g., analytics, notifications).

If you don't have a past project that fits, you may use a representative example such as "Real-time transaction authorization and settlement" or "High-traffic quotes and checkout service."

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...