What to Expect in the N26 System Design Interview

Expect a design round of about one hour, based on banking problems. N26 is a mobile bank that holds a full German banking license, and candidates report design questions from the fintech domain rather than generic social network questions.

One candidate reported the round drawn in Figma, which is a shared drawing tool. You will be asked to design something that moves or records money, and the interviewer grades your trade-offs as closely as your diagram.

The Question Types

Public reports on this round are thin, so treat the list below as a guide to the round rather than a question bank. The topics follow N26's own product and its published architecture.

Account and transaction storage. Design the store that holds accounts and every movement between them, where the central idea is a ledger, which is an append only record of money movements. You never edit a past entry, because a correction is written as a new entry instead.

Payment processing. Design the path a card payment or a bank transfer takes, where the hard parts are idempotency, failure in the middle, and reconciliation. Idempotency means that applying the same request twice has the same effect as applying it once, while reconciliation means comparing your records against the other bank's records and fixing the differences.

Reading long histories. A customer's transaction list grows without limit, so expect questions about paging through it. Compare offset paging, which skips a count of rows, with keyset paging, which continues from the last row you read. Keyset paging stays fast as the history grows, while offset paging gets slower with every page.

Events between services. N26 engineers have written publicly about more than two hundred small services and about Kafka for events. Kafka stores a stream of messages that other services read later, and can read again. Expect questions about which calls belong in a direct request and which belong in an event.

Mobile clients on a weak network. The product is an app first, so expect questions about retries, cached reads, and push notifications for card payments.

Fraud and limits. A bank must block some payments while they happen, so expect questions about rules that run inside the payment path, and about models that run beside it on recent history.

What the Interviewer Grades

State the requirements before you draw any boxes, naming how many customers, how many payments per second, and which failures the system must survive. Then name your trade-offs out loud, rather than waiting for the interviewer to find them.

Correctness scores highest in this round, because a duplicate transfer costs real money. Mention audit records early, since a licensed bank must explain every change later. Candidates report interviewers who ask for depth, so give a reason for each choice.

A Walkthrough: Design the Transfer Service

Here is a high level plan for a question of this kind.

1. Requirements (5 minutes). Transfers run between N26 accounts and out to other banks, and each transfer applies exactly once, with the result appearing in the app within seconds. Every attempt leaves an audit record that someone can read back later.

2. The data model. A ledger table holds one row per movement, with a direction, an amount, a currency, and a reference. Each transfer writes two rows, one out and one in, and the balance is the sum of those rows, which you also keep as a cached running total.

3. Exactly once behavior. The client sends a unique request key with each transfer, and the service stores that key together with the result. A repeat with the same key returns the stored result and writes nothing new.

4. Internal and external transfers. A transfer inside N26 commits both ledger rows in one database transaction. A transfer to another bank cannot do that, so write the rows in a pending state, send the instruction to the payment network, then settle or reverse when the answer arrives.

5. Events and notifications. Publish one event for every settled movement on the ledger. The notification service, the spending category service, and the fraud service all read that stream. A slow reader never blocks the payment path, because the stream keeps the messages for later.

6. Checks and failure. Run a daily comparison between your ledger and the payment network's statement. Hold a payment for review when a limit or a rule rejects it, and keep every request, response, and decision for the audit record.

7. Scale and isolation. Shard the data by account, and keep the money path small and direct. Move reporting and analytics onto read replicas so they never slow a payment.

Common Mistakes in This Round

• Editing balances directly. A design without a ledger fails here, because a balance is derived from movements rather than stored as the only fact.
• Skipping retries. Networks repeat requests, so a design without a request key allows the same payment to apply twice.
• No audit story. A licensed bank must show who changed what and when, so describe the audit record before the interviewer asks for it.
• Ignoring other banks. External payments are slow and can fail after you have already answered the customer, so design the pending state for them.
• Drawing before asking. Candidates report interviewers who expect the requirements first, so spend the first five minutes there.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the databases, queues, and caches every payment design needs.
• Study the hard failure cases. Advanced System Design Interview, Volume II covers replication, consistency, and recovery.
• Rehearse the walkthrough. Practice the seven steps above out loud in under 40 minutes.
• See the whole process. This round is one step of the N26 interview process, which also includes the coding rounds and the motivation question.
• Plan for the wait. How long it takes to hear back after an N26 interview gives the reported gap after this round.