What to Expect in the Starling Bank System Design Interview

The design questions come in the technical interview of about 1.5 hours, after the engineers review your take-home code. Starling's published engineering stages list no separate design round, so the design work and the code review happen in one session. Candidates report an online whiteboard and a scenario they work through together with the interviewers.

Reported questions include designing a workflow for transferring money through a payment gateway, designing a database for a payments scenario, and explaining how a system behaves when a service it depends on fails. Questions about ACID properties are also reported, where ACID names the guarantees a database gives for one transaction: atomicity, consistency, isolation, and durability.

Why the Questions Look Like This

Starling built its own banking platform rather than buying one from a vendor, and its engineers have described that platform in public talks. The round therefore asks about the same problems that the platform itself must solve. Money must move exactly once, and a service that is unavailable for a minute must not lose work. Prepare those problems rather than the generic social feed or chat designs.

The Question Types

Money movement workflows. Design how a transfer moves from one account to another, through a payment scheme or a gateway. A payment scheme is the shared network that banks use to send money between themselves. The hard parts are duplicate prevention, ordering, and the case where the gateway does not answer in time. Candidates report that interviewers describe the gateway as simple: it gives a synchronous API and no callbacks.

Data model questions. Candidates report being asked to design a database for payments on a whiteboard, so expect to defend your ledger design. A ledger is the record of every debit and credit, kept so that any balance can be recomputed from it.

Failure handling. One reported question asks how your system handles the failure of an API it depends on. Answer with queues, retries that wait longer after each attempt, identifiers that make a retry safe, and a background process that finishes the work later.

Operational questions. Starling releases to production several times a day inside a regulated bank, so expect questions about safe releases, monitoring, and how you would discover that a payment went missing.

How the Starling Architecture Answers These

The vocabulary from Starling's public engineering talks is worth learning before the round. Services are self-contained, which means each one owns its own database and exposes an API. A service that receives work validates it, saves it, and returns at once, rather than waiting for the whole task to finish.

Every request has a unique identifier, so running it twice produces the same result as running it once, and that property is called idempotency. Work is written to a database before it is performed, and background processes retry anything unfinished until it completes.

A Walkthrough: Design a Transfer to Another Bank

1. Requirements (about 5 minutes). A customer sends money to an account held at a different bank, and the result must appear in the app quickly. State the targets plainly: never pay twice, never lose a payment, and always show the customer a clear status.

2. The request and the ledger. The client sends a transfer request with an identifier that it generates, and the service stores both the request and a pending ledger entry in one database transaction. A repeated request with the same identifier then finds the first and returns the same answer.

3. The asynchronous handoff. A separate worker reads the stored requests and calls the payment scheme, so the customer call returns once the request is recorded rather than when the scheme replies. Writing the work down before doing it is what keeps a transfer safe across a restart.

4. Failure and retry. If the scheme times out, the outcome is unknown, and that unknown case is the dangerous one. Retry with the same identifier so the scheme can recognize the duplicate, and keep retrying on a schedule until you have a definite answer.

5. Settlement, reconciliation, and alerts. When confirmation arrives, mark the ledger entry settled, and then reconcile every day, which means comparing your own records against the records of the scheme. Alert on any payment that stays pending beyond a time limit you set, and record every state change so that any payment can be traced afterward.

What the Interviewer Grades

Correctness in money movement comes first, ahead of scale and ahead of unusual design choices. State the requirements and the failure cases before you draw anything on the whiteboard. Name your trade-offs out loud, and say which guarantee you are giving up when you choose one.

Candidates describe these sessions as conversational, so think aloud and ask questions while you work. The same interviewers reviewed your take-home code earlier in the session, so keep the design consistent with the choices in that code.

Common Mistakes in This Round

• Treating a failed call as a failed payment. A failed call to a payment scheme is not a failed payment, so say what you do when the outcome is unknown.
• Skipping idempotency. Without an identifier that makes a retry safe, the design can send the same money twice, which is the worst outcome in a bank.
• One shared database. Each Starling service owns its own data, so proposing a single central database for every service is a weak answer here.
• No reconciliation or alerting. A bank checks its own records every day, and it watches for payments that never finish.

How to Prepare

• Learn the basic parts. Grokking the System Design Interview covers the queues, caches, and databases that every payment design needs.
• Study consistency and failure in more detail. Advanced System Design Interview, Volume II covers replication, isolation, and recovery, which are the areas this round tests most.
• Rehearse the walkthrough. Practice the five steps above out loud in under 30 minutes, because the design work shares the session with the code review.
• See the whole process. This round is one of four stages in the Starling Bank interview process, and the other pages cover the motivation question and the reported reply times.