Trade Republic: Products, Business Model, and the Engineer's Role

Learning outcomes

A senior engineer who joins Trade Republic is not handed a service to maintain, they are handed a slice of a regulated money machine and asked to make it faster, cheaper, and safer. That only works if you understand what the machine actually does and where every euro of revenue comes from. This concept builds the map you need before you touch a single service: the product surface, the money flows, and the engineering ownership that connects them.

After studying this page, you can:

• Trace a customer order from the mobile screen to a settled position and name the systems each step crosses.
• Explain how a zero-commission brokerage still earns money, and which money flows are load-bearing for the business.
• Connect each product line (brokerage, cash, bonds, cards) to the engineering problems it creates.
• State the engineer’s role in a domain-team organization and defend why product knowledge is a senior expectation, not optional.
• Recognize the candidate mistakes that signal a weak grasp of the business and correct them.

Before we dive in

The obvious way to think about a stock-trading app is that it is a window onto the market: the customer taps Buy, the app reaches out, shares get bought, the screen updates. If you carry that model into a Trade Republic interview, it will quietly sink you, because it treats the app as a thin client over an exchange that is somebody else’s problem. The reality is that almost none of the value, the risk, or the engineering difficulty lives in the tap. It lives in everything the tap sets in motion: the custody of real securities, the safekeeping of customer cash, the regulatory reporting that must be provable months later, the price quotes that must arrive in real time, and the settlement that must reconcile to the cent across counterparties.

The problem that forced this kind of company into existence is a gap. Traditional brokers charged per-trade commissions and gated investing behind account minimums, paperwork, and latency measured in days. A mobile-first brokerage collapses that gap: it makes buying a fraction of an ETF as frictionless as ordering a ride, and it does so inside a regulatory frame that was designed for slower, heavier institutions. The tension between frictionless consumer experience and heavy financial regulation is the engine of the whole business, and it is the source of almost every interesting engineering decision.

So before any system design, anchor three things. First, Trade Republic is mobile-first: native iOS in Swift and Android in Kotlin with Jetpack Compose are first-class clients, not afterthoughts. Second, it is a regulated entity, a brokerage licensed under German supervision that also operates banking features, which means customer assets and customer cash live under legal separation rules that constrain storage, reconciliation, and failure modes. Third, it is a product-and-technology organization of roughly 280 engineers split into teams by business domain, so a senior engineer owns a business outcome, not a generic platform layer.

The product surface and how money moves

The cleanest way to see the product is to follow a single action, a customer buying an ETF, end to end. Each stop on that path is a system, a team, and a class of failure.

Brokerage: trades and the execution path

A trade begins long before the customer taps. The customer first needs to find the instrument, and discovery is itself a load-bearing product: an instrument recommendation and search experience must return relevant results in tens of milliseconds, backed by Elasticsearch. That latency budget is not vanity, it is the difference between a screen that feels instant and one that feels like a financial website, and the customer’s trust in the app’s speed translates directly into trading activity.

Once the customer opens an instrument, the app shows a live price. That price is not pulled on demand, it is streamed. Quotes arrive from market data sources, are normalized, and are pushed to the device. For some asset classes the displayed number is itself computed, not quoted: bond customers care about yield to maturity, which must be derived from incoming quotes in real time and streamed per instrument. So even the number on the screen is the output of a streaming pipeline, not a database lookup.

The order itself is the heart of the system. The customer submits an order to buy or sell; the system must check the account, route the order for execution, receive a fill, update the position and the cash balance, and confirm back to the device. The failure modes here are exactly the ones interviewers probe: a balance update and the corresponding event to downstream systems cannot share one naive transaction, because the message system does not participate in the database transaction. Get this wrong and you get phantom events, missing fills, or balances that disagree with holdings.

The diagram’s lesson is that “a trade” is not one operation. It is a saga that spans validation, an external counterparty, a ledger mutation, and an event, and the engineer’s job is to make the whole saga either complete or leave a clean, reconcilable state. This is why a candidate who treats the order as a single synchronous call fails the system-design round.

The neobank layer: cash, interest, and cards

Brokerage alone is no longer the whole product. Uninvested customer cash earns interest, customers can pay with a card, and cash moves in and out through transfers. Each of these imports a different set of constraints. Interest accrual is a scheduled computation that must be exact and auditable. A card transaction is an authorization and clearing flow with its own idempotency rules. Cash transfers carry anti-money-laundering checks.

The engineering consequence is that “the account” is not one number in one table. It is a ledger of immutable entries that must reconcile against external bank records, and a position store that must reconcile against the custodian that actually holds the securities. Two sources of truth, the internal ledger and the external custodian or bank, must agree, and when they disagree somebody must explain the discrepancy before the market opens the next morning.

The reconciliation mindset

In a regulated money business, the system of record is rarely a single store. The internal ledger is one view; the custodian, the bank, and the card network each hold their own. Senior engineering judgement here is less about building a fast service and more about guaranteeing that every internal number can be tied back to an external authority, every day, without exception.

How the business actually earns

A candidate who cannot answer “how does a zero-commission broker make money?” has not done the basic homework, and interviewers notice. The answer matters for engineering because the money flows decide which systems must never fail and which can degrade gracefully.

A modern broker earns from several streams that sit on top of the order flow. Execution partners, the market makers and venues that fill retail orders, compensate the broker for routing order flow to them; this is the dominant revenue line for many commission-free brokers. The broker earns a foreign-exchange margin when a customer trades an asset in a currency other than their account currency, because the broker performs the currency conversion. Uninvested cash that earns interest is itself a revenue source, because the broker earns on the cash it holds while paying the customer a portion. Card spending generates interchange. None of these is a per-trade customer commission, which is why the headline can be zero commission while the business is profitable.

The engineering implication is direct. The order-routing path is load-bearing for revenue, so its correctness and its audit trail are non-negotiable. The cash-interest path is a scheduled accrual that must be exact and reconcilable. The card path must handle the asynchronous, eventually-consistent world of payment networks. A senior engineer reasons about reliability in proportion to revenue exposure: the system that routes the order earns the money, so its failure is a revenue failure, not just a bug.

What the engineer owns

Trade Republic organizes its roughly 280 engineers into teams aligned to business domains rather than to horizontal platform layers. This is a deliberate choice with a deliberate cost. The benefit is that a team owns a business outcome end to end, from the mobile screen through the backend to the data, so there is no handoff queue where a feature dies. The cost is that each engineer must carry product knowledge, because nobody on the team can say “that is the platform team’s problem.”

A senior engineer’s role in this shape is different from a pure platform role. You are expected to know which instruments your domain trades, what a fill means operationally, why settlement takes the time it takes, and what the regulator will ask to see if something goes wrong. You are also expected to drive technical decisions through a written architecture process, recorded as RFCs and architecture decision records, with significant choices reviewed by a forum of Senior and above engineers. The autonomy is real, but it is bounded by alignment mechanisms, and the Tech Radar is one of those mechanisms.

The snippet is deliberately not about a clever algorithm. It is about the shape of ownership: a domain concept expressed in code, transaction safety, idempotency, and rollback. That shape is what a Trade Republic interviewer is listening for.

Where the design breaks at scale

Every choice above has a scale where it cracks. The follow-up questions an interviewer asks are designed to find the crack and see whether you reason about it or panic.

The streaming price path cracks first under volume. A naive fan-out that subscribes every connected device to a raw feed drowns the service, which is why real systems fan one instrument’s updates to many WebSocket clients through a shared flow and create a backend subscription only when the first client needs it, tearing it down when the last client leaves. Assume the opposite and your design fails the “millions of users” constraint.

The order path cracks on the dual-write problem. As soon as a fill must update a balance and publish an event, and the publish cannot join the database transaction, you have a window for inconsistency. The fix is the outbox pattern, and a senior candidate names it unprompted. The deeper crack is that the outbox itself becomes a bottleneck at high throughput, so production outboxes are partitioned, indexed on unpublished rows, and drained in bounded batches to avoid long transactions that block vacuuming.

The search path cracks on latency budget. A recommendation that must return in tens of milliseconds cannot afford a heavy join or a cold cache miss on every keystroke, so retrieval is offloaded to a search engine and the ranking is tuned to the budget.

The reconciliation path cracks on volume of entries. A ledger that works at thousands of entries a day becomes a query-planning and partitioning problem at millions, which is why database statistics, partitioning strategy, and index bloat become senior-level concerns, not afterthoughts.

Common mistakes candidates make

A short catalog of the failure modes that recur, each one a signal the candidate has not internalized the business.

The first is treating the app as a thin client over an exchange. The candidate draws a box labeled “exchange” and assumes the broker’s job is to forward requests. The correct model is that the broker is the system of record for the customer, custody is the broker’s responsibility, and the exchange is one of several counterparties. An interviewer who asks “where does the customer’s share actually live?” is testing exactly this.

The second is ignoring transaction rollback on failure. A candidate writes the happy path, updates the balance, and moves on. When asked what happens if execution fails after the balance is charged, there is no rollback and the customer is left with a charge and no fill. This is a documented failure mode, and recovering it correctly (rollback, or a compensating transaction in a saga) is what separates a working design from a broken one.

The third is assuming all exchanges and data sources provide consistent formats. Real ingestion must normalize heterogeneous quote formats and recover from missing or malformed fields, and a candidate who assumes a clean, uniform input reveals no production experience.

The fourth is building a monolithic ingestion service instead of a horizontally scalable one. Under load a single ingestion worker becomes the bottleneck and the blast radius of its failure is the whole market-data feed. The senior answer is partitioned, horizontally scaled workers, which is the documented preference over a monolith.

The fifth, and the one that sinks behavioral rounds, is a self-centric motivation. A candidate who frames the whole conversation around personal career growth, technology novelty, and what they will learn, without ever connecting to the mission of broadening access to investing, reads as a poor cultural fit. The business mission is the frame interviewers grade against.

Mastery Questions

Question

A customer taps Buy on an ETF. Walk the systems the order crosses before the position settles, and name the one step a weak candidate forgets.

Question

If the broker charges zero per-trade commission, where does the revenue come from, and which revenue line makes the order-routing path non-negotiable?

Question

Why is the displayed bond yield a streaming pipeline output and not a database lookup?

Question

The balance is updated and then an event is published to a bus. The bus does not participate in the database transaction. Name the failure and the fix.

Question

A candidate proposes one large ingestion worker that normalizes all market-data feeds. Why is this the wrong shape, and what replaces it?

Question

Why does Trade Republic organize engineers into domain teams rather than horizontal platform teams, and what does that demand of a senior engineer?

Question

An interviewer asks why a recommendation screen must return in tens of milliseconds. Give the business reason, not the technical one.

Answer

The order crosses instrument search and live quote streaming, then order validation and risk check, routing to an execution counterparty, receipt of the fill, ledger mutation of cash and holdings, and an event to downstream systems such as notifications. The step weak candidates forget is the transactional coupling of the ledger mutation and the event: the event publish cannot join the database transaction, so an outbox must write the event in the same transaction, or a fill can land without a notification or vice versa.

Answer

Revenue comes from payment for order flow (execution partners compensate the broker for routing retail orders), foreign-exchange margin on non-account-currency trades, interest on uninvested customer cash, and card interchange. The order-routing path is non-negotiable because payment for order flow is earned precisely when an order is routed and filled, so a failure or inaccuracy there is a direct revenue failure and an audit-trail failure, not merely a bug.

Answer

Bond customers decide on yield to maturity, not on a raw price quote. Yield must be computed from incoming quotes in real time, per instrument, and pushed to the device. The pipeline consumes raw quotes, computes the yield, and sinks it both to a cache for immediate WebSocket delivery and to a topic for historical charts. Treating it as a lookup would serve stale yield precisely when it matters most, during quote bursts.

Answer

This is the dual-write problem. If the publish happens after the commit and the publish fails, the balance changed but no event was emitted, a phantom state. If the publish happens before the commit and the commit fails, an event was emitted for a change that never happened. The fix is the outbox pattern: write the event row in the same transaction as the balance change, so both succeed or both fail, then a separate publisher drains the outbox to the bus.

Answer

A monolithic ingestion worker is a single bottleneck and a single blast radius: when it fails or saturates, the entire market-data feed degrades. The senior answer is horizontally scaled, partitioned workers, each owning a slice of the feed, so load spreads and a single worker's failure affects only its partition. This matches the documented preference for partitioned, scalable batch and ingestion workers over a monolith.

Answer

Domain teams own a business outcome end to end, from mobile through backend to data, eliminating the handoff queues where features stall in a layered organization. The cost is that product knowledge cannot be outsourced: a senior engineer must understand the instruments, the settlement timing, and the regulatory questions, and must drive decisions through written RFCs and architecture records reviewed by a Senior-and-above forum. Ownership is a business outcome, not a generic platform layer.

Answer

The latency budget is a conversion mechanism, not a vanity metric. A screen that feels instant builds trust in the app's competence and keeps the customer in the flow that leads to investing; a screen that feels like a slow financial website causes abandonment. The speed translates directly into trading activity and therefore into the order flow that earns revenue, which is why the retrieval is offloaded to a search engine tuned to the budget.

Question

A customer taps Buy on an ETF. Walk the systems the order crosses before the position settles, and name the one step a weak candidate forgets.

Answer

The order crosses instrument search and live quote streaming, then order validation and risk check, routing to an execution counterparty, receipt of the fill, ledger mutation of cash and holdings, and an event to downstream systems such as notifications. The step weak candidates forget is the transactional coupling of the ledger mutation and the event: the event publish cannot join the database transaction, so an outbox must write the event in the same transaction, or a fill can land without a notification or vice versa.

Prev1 / 7Next