What to Expect in the Nubank System Design Interview

The Nubank system design interview is an architecture discussion on an online whiteboard such as Miro or Excalidraw. Candidates report scenarios from Nubank's own domain: ledger systems, payments, and fraud detection. Interviewers test consistency models, idempotency, and event-driven design, often with Kafka as the assumed transport. The priority is correctness first. A bank must never lose, duplicate, or invent money, even during failures.

How Nubank Thinks About Systems

Nubank's engineering culture is public and specific, and it changes what a good answer sounds like.

• Immutable data. Nubank builds with functional programming, where data is not changed in place. New facts are appended, and history is kept. Designs that keep an append-only record fit this culture.
• Events over calls. Candidates report event-driven architecture as a recurring topic. Services publish events to Kafka, a system that carries streams of events, and other services react.
• Consistency by choice. Expect the ACID versus BASE question. ACID means a database applies a transaction fully or not at all. BASE means parts of the system may briefly disagree and then converge. A good answer chooses per flow: ACID for the ledger, BASE for notifications.

The Question Types

• Ledger design. Build the record of account balances and movements. The ledger is the source of truth, and read models are derived from it.
• Payment flows. Move money between accounts or to another bank, with retries that cannot double-pay. Idempotency, a repeated request having the effect of one, is the required word.
• Fraud detection. Score transactions in real time and block bad ones without slowing good ones.
• Scaling reads. Serve millions of app users their balance and statement quickly while writes stay strictly correct. The usual answer is a read model: a fast copy of the data, rebuilt from ledger events.

A Signature Question: Design Real-Time Fraud Detection

Here is a high-level pass at the most Nubank-shaped question.

Requirements. Every card transaction gets a decision: approve, block, or flag for review. The decision must arrive fast enough for a card terminal, well under one second. Missed fraud costs money. False blocks cost trust. Say this trade-off out loud, because it decides every later choice.

The flow. The authorization service publishes each transaction as an event. A decision service consumes it, computes features, and returns a verdict. Features are numeric facts about the transaction, such as amount versus the customer's usual spending.

Feature store. Real-time features need precomputed state: spending averages, device history, and location patterns. A fast key-value store serves these in a few milliseconds, updated by stream jobs that consume the same events.

Rules plus model. Run cheap hard rules first, such as blocked merchants. Then a trained model scores the rest. Keep a clear threshold policy: approve below one score, review between, block above.

Correctness details. The decision must be idempotent per transaction identifier, because retries happen. Every decision is appended to an audit log, an unchangeable record that reviewers can replay. If the scoring service fails, define the fallback openly: approve small amounts, block large ones, and alert.

The follow-up questions. Expect "how do you update the model without downtime?" The answer: run old and new models in parallel, compare results, then switch. Also expect "how do you keep features fresh?" The answer: measure the delay from event to feature store, and alert when it grows.

How to Prepare

• Master the fintech building blocks. Ledgers, idempotency, event streams, and consistency choices appear in every scenario. Grokking the System Design Interview covers the method, and Grokking the Advanced System Design Interview treats consistency and failure in depth.
• Practice on a whiteboard tool. Rehearse one design in Excalidraw or Miro so the tool does not slow you down in the interview.
• State your consistency choices out loud. For each part of the design, say whether it needs ACID or can accept BASE, and why.
• Bring rough numbers. Estimate events per second and storage growth before the interviewer asks. Simple arithmetic, said early, marks you as senior.
• See the full loop. The design round sits inside a six-stage process. What is the Nubank interview process like? shows what surrounds it, and Top Nubank behavioral interview questions prepares the values conversation.