Revolut System Design Interview Prep

What are Functional Requirements?

What the system does. These describe the features and behaviors a user can see and interact with. Think of them as the "user story" answers.

Example: "A user can send money to another user" / "The system shows a transaction history" / "The system converts currencies in real-time."

If you removed a functional requirement, the user would notice something missing.

What are Non-Functional Requirements?

How the system behaves. These describe qualities and constraints that users feel but don't directly interact with. They're the "-ilities": scalability, reliability, security, performance.

Example: "The system handles 10,000 requests/second" / "Pages load in under 2 seconds" / "Data is encrypted at rest and in transit" / "99.9% uptime."

If you violated a non-functional requirement, the system would still work but would be slow, insecure, or crash under load.

What does "Real-time vs Eventual Consistency" mean?

Real-time (strong) consistency: When you send money, the balance updates instantly everywhere. If you check on another device 1 millisecond later, you see the new balance. This is slower because all parts of the system must agree before responding.

Eventual consistency: After you send money, there's a brief delay (milliseconds to seconds) before all parts of the system reflect the new state. Faster and more scalable, but you might briefly see stale data.

In a payment system you typically want both: Strong consistency for the transaction itself (don't allow overdraft — the balance must be accurate at the moment of transfer). Eventual consistency is fine for displaying transaction history (ok if it appears 1-2 seconds later on another screen).

This is a great question to ask the interviewer: "For the core transfer operation, do we need strong consistency, or is eventual consistency acceptable?" It shows you understand the trade-off between speed/scalability and data accuracy.

// Remote data with a caching layer (e.g. React Query, SWR, or custom)
const { data: balance, isLoading } = useQuery({
  queryKey: ['balance', accountId],
  queryFn: () => api.getBalance(accountId),
  staleTime: 30_000, // consider fresh for 30s
  refetchOnWindowFocus: true,
});

// After a successful transfer, invalidate cached data so it refetches
const mutation = useMutation({
  mutationFn: api.createTransfer,
  onSuccess: () => {
    queryClient.invalidateQueries({ queryKey: ['balance'] });
    queryClient.invalidateQueries({ queryKey: ['transactions'] });
  },
});

// Error boundary per module
<ErrorBoundary fallback={<TransferErrorFallback />}>
  <TransferModule />
</ErrorBoundary>

// API interceptor
api.interceptors.response.use(null, (error) => {
  if (error.response?.status === 401) {
    return refreshTokenAndRetry(error.config);
  }
  return Promise.reject(normalizeError(error));
});

Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

{
  "from_account_id": "acc_123",
  "to_account_id": "acc_456",
  "amount": 10000,
  "currency": "EUR",
  "description": "Rent payment"
}

{
  "data": {
    "id": "txn_789",
    "status": "pending",
    "amount": 10000,
    "currency": "EUR",
    "from_account_id": "acc_123",
    "to_account_id": "acc_456",
    "created_at": "2026-04-08T10:00:00Z"
  }
}

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 97
X-RateLimit-Reset: 1712570400

{
  "data": {
    "id": "txn_789",
    "status": "completed",
    "amount": 10000,
    "currency": "EUR",
    ...
  }
}

page     = 1          // page number
limit    = 20         // items per page
status   = completed  // filter (optional)
currency = EUR        // filter (optional)
from     = 2026-01-01 // date range (optional)

{
  "data": [ ...transfers ],
  "pagination": {
    "page": 1,
    "limit": 20,
    "total": 142,
    "has_next": true
  }
}

Response 200:
{
  "data": {
    "account_id": "acc_123",
    "balance": 250000,     // minor units: 2500.00 EUR
    "currency": "EUR",
    "updated_at": "2026-04-08T10:00:00Z"
  }
}

// HTTP 400 / 401 / 403 / 409 / 429 / 5xx
{
  "error": {
    "code": "INSUFFICIENT_FUNDS",        // machine-readable, for frontend logic
    "message": "Account balance is too low", // human-readable, for display
    "details": {                          // optional context
      "available": 5000,
      "required": 10000
    }
  }
}

These are RESPONSE headers — the server sends them back to you

Rate limiting protects the server from being overwhelmed. The server tracks how many requests each client makes and includes these headers in every response so the client knows where it stands:

X-RateLimit-Limit: 100 — "You're allowed 100 requests per time window"
X-RateLimit-Remaining: 97 — "You have 97 requests left in this window"
X-RateLimit-Reset: 1712570400 — "Your limit resets at this Unix timestamp"

When remaining hits 0: The server responds with 429 Too Many Requests and a Retry-After: 30 header telling the client to wait 30 seconds.

Frontend should: Read these headers, show a user-friendly message if rate limited ("Please wait a moment before trying again"), and implement exponential backoff with jitter for automatic retries.

How to retry failed/rate-limited requests without making things worse

The problem: If 1000 clients all get rate-limited at the same time and all retry after exactly 2 seconds, they'll all hit the server again simultaneously — creating a "thundering herd" that crashes it again.

Exponential backoff: Each retry waits longer than the last: 1s → 2s → 4s → 8s → 16s (doubling each time, with a max cap).

Jitter: Add a random delay on top so not everyone retries at the exact same moment. Instead of all clients retrying at 4s, one retries at 3.2s, another at 4.7s, another at 5.1s — spreading the load.

// Exponential backoff with jitter
function getRetryDelay(attempt, baseMs = 1000, maxMs = 30000) {
  const exponential = baseMs * Math.pow(2, attempt);  // 1s, 2s, 4s, 8s...
  const capped = Math.min(exponential, maxMs);         // never more than 30s
  const jitter = capped * (0.5 + Math.random() * 0.5); // add randomness
  return jitter;
}

// attempt 0 → ~1.0-1.5s
// attempt 1 → ~2.0-3.0s
// attempt 2 → ~4.0-6.0s
// attempt 3 → ~8.0-12.0s (spreading the retries)

When to give up: Set a max number of retries (e.g. 3-5). After that, show the user an error: "Transfer couldn't be completed. Please try again later." Don't retry forever.

Stop calling a service that's clearly down — give it time to recover

Think of it like an electrical circuit breaker in your house: when there's too much load, it trips and cuts the connection to prevent damage.

Three states:

CLOSED (normal) — Requests flow through normally. The circuit tracks failure count.
OPEN (tripped) — Too many failures detected (e.g. 5 failures in 10 seconds). Requests are immediately rejected without calling the server. Show cached data or a fallback UI. This gives the server time to recover instead of hammering it with more requests.
HALF-OPEN (testing) — After a timeout (e.g. 30 seconds), let ONE request through to test if the service recovered. If it succeeds → back to CLOSED. If it fails → back to OPEN.

On the frontend this means: If the balance API fails 3 times in a row, stop calling it. Show the last cached balance with a note "Balance may be outdated" and a manual "Retry" button. After 30 seconds, try again automatically.

In the interview, mention it when discussing: failure scenarios, graceful degradation, or how the frontend handles a backend outage.

The problem: POST is NOT idempotent by nature

Idempotent means "doing it twice has the same effect as doing it once."

GET /transfers/123 — Naturally idempotent. Reading data 10 times changes nothing.
PUT /transfers/123 {amount: 100} — Naturally idempotent. Setting a value to 100 twice still gives 100.
DELETE /transfers/123 — Naturally idempotent. Deleting twice? Already gone after the first.
POST /transfers {amount: 100} — NOT idempotent! Sending twice = two transfers = user charged twice!

The fix: The client attaches an Idempotency-Key header (a UUID it generates). The server uses this key to detect retries and return the original response without processing again.

Core Web Vitals — Google's 3 metrics for user experience

These are measured in the user's real browser and reported back. Google uses them for search ranking too.

LCP = Largest Contentful Paint — How long until the biggest visible element (hero image, main text block) appears on screen. Measures "when does the page look loaded?"
Good: < 2.5s   Needs work: 2.5-4s   Poor: > 4s

INP = Interaction to Next Paint — How long between the user clicking/tapping something and the screen visually responding. Measures "does the page feel responsive?"
Good: < 200ms   Needs work: 200-500ms   Poor: > 500ms

CLS = Cumulative Layout Shift — How much the page content jumps around while loading (e.g. an image loads late and pushes text down, or an ad inserts above the button you were about to click). Measures "does the layout stay stable?"
Good: < 0.1   Needs work: 0.1-0.25   Poor: > 0.25

API Latency Percentiles — p50, p95, p99

Instead of "average response time" (which hides outliers), we use percentiles:

p50 (median) — 50% of requests are faster than this. This is your typical experience.
p95 — 95% of requests are faster than this. Only 1 in 20 is slower. This is what most users experience at worst.
p99 — 99% of requests are faster than this. Only 1 in 100 is slower. This catches the worst-case outliers.

Example: "Our transfer API has p50 = 120ms, p95 = 450ms, p99 = 1200ms" means: most requests complete in 120ms, but 1 in 100 takes over a second — probably worth investigating why.

Why not average? If 99 requests take 100ms and 1 takes 10,000ms, the average is 199ms — looks fine. But p99 = 10,000ms tells you something is badly wrong for some users.

In the interview, say: "We'd monitor p50, p95, and p99 latency — averages hide problems."

Apdex — Application Performance Index

A single number from 0 to 1 that summarizes user satisfaction based on response time.

You define a threshold T (e.g. T = 500ms). Then:

Satisfied — response < T (under 500ms)
Tolerating — response between T and 4T (500ms - 2s)
Frustrated — response > 4T (over 2s) or errors

Apdex = (Satisfied + Tolerating/2) / Total. Score of 1.0 = everyone happy. Score of 0.5 = half your users are frustrated. Simple way to answer "are users happy with performance?"

RTL Languages (Right-to-Left)

Languages like Arabic, Hebrew, and Farsi are read and written from right to left. This flips the entire UI layout:

What changes in RTL mode:

• Text alignment — defaults to right-aligned instead of left
• Layout direction — sidebars, nav items, icons all mirror horizontally
• CSS — use margin-inline-start / padding-inline-end instead of margin-left / padding-right (logical properties)
• Icons with direction — arrows, "back" buttons must flip; but icons like a clock or checkmark do NOT flip
• Numbers and dates — digits themselves are still LTR, but surrounding text is RTL

How to mention in interview: "We set dir="rtl" on the HTML element and use CSS logical properties so the entire layout mirrors automatically. We avoid hardcoded left/right in CSS."

Loading States — Beyond Spinners

Showing a spinner for every loading state is a bad UX pattern. It makes the app feel slow and causes layout shift (bad for CLS). Here are better approaches:

1. Skeleton screens (best for initial loads)
Show grey placeholder shapes that match the layout of the content about to appear. The user sees the page "structure" instantly, then content fills in. No layout jump.

• Use for: page loads, list items, cards, profile sections
• Why: preserves layout, perceived performance is much better than a blank screen + spinner

2. Optimistic UI (best for user actions)
Immediately show the expected result before the server confirms. If the server fails, roll back and show an error.

• Use for: like buttons, toggles, sending messages, adding to favourites
• Why: the action feels instant — users don't wait for a round-trip
• Example: "User taps 'Send money' → we immediately show 'Transfer pending' in the list → server confirms or we roll back"

3. Stale-while-revalidate (best for cached data)
Show the last known data immediately, then fetch fresh data in the background. When the new data arrives, update silently.

• Use for: transaction history, account balance (show last known, update when fresh data arrives)
• Why: the screen is never empty — there's always something useful to show

4. Progressive / incremental loading
Load and render critical content first, then load secondary content after.

• Use for: dashboards (show summary cards first, then charts), long lists (virtualisation / infinite scroll)
• Why: user sees actionable content faster, even if the whole page isn't ready

5. Inline loading indicators (when you must show "loading")
Small, contextual indicators right where the action happened — not a full-page overlay.

• Use for: submit button → disable + tiny spinner inside the button; pull-to-refresh indicator
• Why: user knows exactly what is loading and can still interact with the rest of the page

How to mention in interview: "For loading states, I'd use skeleton screens for initial page loads to avoid layout shift, optimistic updates for user actions like transfers, and stale-while-revalidate for cached API data so the screen is never blank. Full-page spinners are a last resort."