Nubank System Design Interview: Ledger, Kafka & Idempotency

Last updated: September 2026

Quick Answer

The Nubank system design interview is a 45 to 60 minute discussion round where you design a fintech system end to end. Reported prompts cluster around three shapes: a double-entry ledger, a real-time fraud or risk pipeline, and a credit limit or authorisation service. Interviewers score consistency reasoning, idempotency, immutability and failure handling far more than diagram tidiness. Rehearse one ledger design aloud in OphyAI Coding Interview first.

Element	What candidates report
Format	Discussion or whiteboard, no code required
Duration	45-60 minutes
Interviewers	One or two engineers, often from a platform or core banking team
Prompts	Ledger, fraud or risk pipeline, credit limit service, authorisation path
Language	Clojure knowledge is not required, but functional thinking is noticed

What Nubank Is Testing in This Round

Nubank is testing whether you reason about money the way its own systems do. The company built its core in Clojure with Datomic and Kafka on AWS, following a hexagonal architecture with largely immutable data, and it runs real-time double-entry accounting at a scale its engineering blog puts at more than 122 million customers. Those choices are the answer key.

Interviewers listen for four things: whether you treat records as immutable facts and derive state from them rather than mutating a balance; whether you raise idempotency yourself when a transaction API appears; whether you can name a real consistency trade-off and say which side each component sits on; and whether you design for partial failure, meaning the authorisation that times out, the message delivered twice, the partner network that stops responding mid-transaction.

What to Expect

The round is conversational. You get a one-line prompt, you ask clarifying questions, and you drive. There is no coding platform and no expectation that you know Clojure syntax.

Expect the interviewer to intervene roughly every ten minutes with a constraint that breaks your design: volume goes up tenfold, a downstream service becomes unavailable, a regulator asks you to reproduce a balance as it stood three months ago. That last one is the most Nubank-flavoured probe there is, because an append-only, time-aware data model answers it immediately and a mutable balance table does not.

Rehearse against those interruptions in OphyAI Interview Practice, where the system design format asks the next question rather than letting you monologue.

Example Questions and How to Answer Them

”Design a double-entry ledger for a digital bank.”

Approach: Start with the invariant: every transaction writes at least two entries and the sum across accounts is always zero. Model entries as immutable append-only facts with a transaction identifier, and derive balances by aggregation with a materialised view for reads. Then handle the hard parts out loud: idempotency keys so a retry does not double-post, ordering within an account, and reconciliation against an external partner. Say explicitly that you would not update a balance in place.

”Design the authorisation path for a card transaction.”

Approach: Nubank’s authoriser is a real-time approval system with a hard latency budget and a live connection to a card network. Walk the path: message in, risk and limit checks, hold placed, response out, settlement later. Name the budget you design to and what you shed first when you cannot meet it. Then cover the timeout: you approve, the response never lands, and settlement must reconcile with your hold.

”Design a real-time fraud detection pipeline.”

Approach: Nubank’s engineering writing describes a risk platform built on Clojure, Datomic and Kafka. Structure it as ingestion, feature computation, scoring and action, with Kafka as the backbone. The real trade-off is where synchronous scoring stops and asynchronous review starts, because an inline model is bounded by the authorisation latency budget. Cover feature freshness and the feedback loop where blocked transactions never generate labels.

”Design a credit limit service.”

Approach: A limit is both a policy decision and a real-time constraint, so separate them: an offline decisioning system that recomputes eligibility from behaviour and bureau data, and a low-latency service that answers whether a transaction fits the available limit right now, including unsettled holds. Cover how a limit change propagates, what happens to in-flight authorisations, and how you would audit any specific limit.

How to Prepare in 3 Days

Day 1. Learn the vocabulary: double-entry accounting, authorisation versus settlement, holds, idempotency keys, at-least-once delivery, event sourcing. Read Nubank’s engineering blog so you can name its actual components.

Day 2. Design the ledger and the authoriser end to end on paper, then again out loud against a clock. Reach failure handling within the first fifteen minutes.

Day 3. Run a full mock with follow-ups in OphyAI Interview Practice using the system design format, and drill one design under time pressure in OphyAI Coding Interview. Nubank publishes no policy on candidate AI use in interviews, so ask your recruiter and treat Interview Copilot as a mock-round tool here. Start practicing →

Common Mistakes

Designing a generic web system. Rate limiters, CDNs and cache tiers are not what this round is about. The money path is.

Waiting to be asked about idempotency. Raising it yourself is a positive signal. Waiting is a negative one.

Mutating balances. Updating a single balance column contradicts everything Nubank built, and the auditability follow-up will expose it.

Claiming strong consistency everywhere. That is not a safe answer, it is an unexamined one. Draw the line and defend it.

Ignoring the partner network. Card networks time out and retry. A design with no story for duplicate inbound messages is incomplete.

Related Guides

• Nubank interview guide
• Revolut system design interview
• System design interview guide
• Plaid interview guide

Frequently Asked Questions

Do I need to know Clojure for the Nubank system design interview?

No. Candidate reports agree the round is language-agnostic and no code is written. What interviewers notice is whether functional habits appear in how you describe state: immutable facts rather than mutation, and derived views rather than one authoritative mutable row. You can show that in plain English.

What system design questions does Nubank ask?

Reported prompts are fintech systems rather than generic web architecture: a double-entry ledger, a real-time fraud detection pipeline, a credit limit service, and the authorisation path for a card transaction. Follow-ups add a failure mode or a regulatory requirement, such as reproducing a balance as it stood on a past date.

How long is the Nubank system design round?

Candidates report 45 to 60 minutes as a discussion or whiteboard session with one or two engineers. Allowing for introductions and your own questions, that is roughly 40 minutes of design time: enough for one system covered properly, not enough for a tour of everything you know.

What is Nubank’s technology stack?

Nubank built its core services in Clojure with Datomic as the database, running on top of DynamoDB, and Kafka for messaging, deployed on AWS. The architecture is microservice-based, follows hexagonal architecture principles with largely immutable data, and runs real-time double-entry accounting with customer and temporal sharding.

Sources and verification notes

Sources checked September 2026. Direct first-party fetches were blocked by this environment’s network policy, so first-party material was consulted through search summaries and labelled below by origin. Nubank publishes no question bank, so prompts and round formats here are candidate-reported.

• Building Nubank, ten years of engineering lessons: first-party, customer scale and architectural evolution.
• Building Nubank, scaling fraud defence: first-party, the Clojure, Datomic and Kafka risk stack.
• InfoQ, Architecting a Modern Financial Institution: talk by Nubank engineers on hexagonal architecture, double-entry accounting and sharding.
• Building Nubank, Datomic licensing: first-party, Datomic as critical infrastructure.
• Glassdoor, Nubank senior software engineer interviews: candidate-reported formats. Self-reported.
• TechPrep, Nubank interview process: reported design prompts and idempotency emphasis. Third-party.