What to Expect in the Trade Republic System Design Interview

Expect one dedicated system design round, run by two senior engineers. Candidates report design questions taken directly from Trade Republic's own product. One reported question is "Design the infrastructure that regularly executes saving plans", and another asks how you would implement an automatic investment tool that runs every billing period.

You will not get a generic photo sharing question. You will get a scheduled job that moves customer money inside a regulated bank, and correctness matters more than cleverness.

The Question Types

Scheduled execution of savings plans. This is the reported signature question, and it deserves most of your preparation time. A savings plan is a standing instruction to buy a fixed amount of a stock, an exchange traded fund (ETF), or a crypto asset on a schedule. Plans execute on fixed dates each month, or on the next trading day when the exchange is closed, so very large numbers of them execute inside one trading window.

Order routing and execution. An execution venue is the exchange or market that completes a trade, and Trade Republic routes equity orders to one venue rather than to many venues at once. Candidates do not report this as a standalone question, so treat it as follow-up material.

Settlement and the ledger. Settlement is the step where cash and securities actually change owners after a trade, and a ledger is the record of every balance and every movement. These are not reported as named questions, but they appear in follow-up questions.

Market data and live updates. The app shows live prices, so expect some discussion of fan-out, which means sending one price update to many connected clients.

Why Savings Plan Execution Is the Signature Problem

The product makes this problem unavoidable, because savings plans all execute on the same few dates. All of that work therefore starts at the same time, inside fixed exchange hours, and all of it moves customer money.

The engineering blog shows the same concerns in public. Published topics include scaling batch jobs for reliable processing, the outbox pattern on PostgreSQL, and streaming events from PostgreSQL into Kafka with Debezium. Reading those topics first gives you the vocabulary the interviewers use.

A Walkthrough: Savings Plan Execution

1. Requirements (about five minutes). State the numbers and the guarantees plainly: a very large number of active plans, a few execution dates each month, and all executions inside exchange trading hours. The guarantee that matters most is that every plan executes once on its date and never twice.

2. Data model and due work. Store each plan with its instrument, amount, schedule, and next execution date, then create one execution record per plan per date with a unique key on that pair. Read the due plans in pages, then split them across workers by a hash of the plan identifier, so no two workers claim the same plan.

3. Placing orders. Group many small plan orders for the same instrument into larger venue orders where the rules allow it, then allocate fractional quantities back to each customer afterward. A fractional quantity is a piece of a share smaller than one whole unit.

4. Writing state safely. Write the order intent and the state change in one database transaction, using an outbox table that stores pending messages beside the business data, so no message is lost when a service restarts. A separate process publishes those messages to the event stream, and the unique key on plan and date makes a repeated delivery harmless.

5. Failures and retries. A worker can stop in the middle of a run, so make every step idempotent, which means that running it twice has the same effect as running it once. Send failed plans to a retry queue with a retry limit, then report whatever still fails for manual review.

6. Reconciliation and monitoring. After the trading window ends, compare your execution records against the venue and custody confirmations, which is what reconciliation means. Track plans due, plans executed, orders rejected, and time to finish the window. Raise any difference as an alert rather than a log line.

What the Interviewer Grades

Practical judgment counts for more than unusual parts, so state the requirements and the failure cases before you draw anything. Name the money edge cases without being asked: insufficient cash, a suspended instrument, a closed account, and a plan canceled during the window. Say each trade-off out loud with the reason you accepted it, because a duplicated order is a real loss.

Reports describe deep follow-up questions, so defend each decision with a reason, and say plainly when something is outside your experience.

Common Mistakes in This Round

• Designing for peak read traffic only. The hard part here is scheduled writes that move money, not reads that serve many users.
• No duplicate protection. A design without idempotency keys or unique constraints fails this round, whatever else it contains.
• Ignoring exchange hours. Work that cannot finish inside the trading window is not a working design.
• Skipping reconciliation. If you cannot prove that every due order was placed exactly once, the design is unfinished.
• Forgetting the regulator. A licensed bank needs audit records of who did what and when, so mention that early.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the queues, jobs, and databases this design needs.
• Study the harder cases. Advanced System Design Interview, Volume II helps with partitioning, replication, and failure handling.
• Rehearse the walkthrough out loud. Practice the six steps above in under 40 minutes, with a simple diagram.
• See the whole process. The design round is one stage of the Trade Republic interview process, and the same product research answers why Trade Republic.
• Plan for the wait after it. How long it takes to hear back describes the reported gaps between rounds.