Trade Republic's Tech Stack and Tech Radar

Learning outcomes

Knowing a list of technologies is not the same as understanding why each one was chosen and how the choice is governed. A senior engineer at Trade Republic is expected to reason about the stack as a set of deliberate bets, each sitting in a governed ring, rather than as a fixed inheritance. This concept walks the actual stack, then the mechanism that controls its evolution, so you can defend a technology choice in an interview the way the organization actually makes one.

After studying this page, you can:

• Map the major layers of the stack to the job each does and the alternative it displaced.
• Explain what a Tech Radar is, its rings and quadrants, and why it exists in a domain-team organization.
• Describe how a technology moves from assess to adopt, and the role of RFCs, architecture decision records, and the architecture forum.
• Reason about cloud security without static keys and why that matters for a regulated business.
• Diagnose where each layer of the stack cracks under scale and what a senior engineer does about it.

Before we dive in

The naive model of a tech stack is a list on a careers page: “we use Kotlin, Postgres, Kafka.” Read that way, the stack is a fact to memorize and recite. The model collapses the moment you ask the question that actually matters, which is why. Why Kotlin and not Java for the new service? Why Postgres and not a NoSQL store for the ledger? Why Kafka and not a simpler queue? The answers are not arbitrary preferences, they are load-bearing decisions made inside an organization that balances two opposing forces: the speed of innovation that a fast-moving fintech needs, and the security and compliance that a regulated neobank must hold. Every line in the stack sits on that tension.

The problem that forced the Tech Radar into existence is the cost of uncoordinated choice. An organization of roughly 280 engineers split into autonomous domain teams could, without a governing mechanism, fragment into a dozen private technology islands, each with its own language, its own datastore, and its own deployment story. The blast radius of that fragmentation is operational: on-call engineers cannot reason across services, hiring is harder, and the security team cannot audit a moving target. The Radar exists to provide explicit alignment without harming velocity, so that autonomy and alignment are not in conflict but in tension, deliberately managed.

So the stack and the Radar are one system. The stack is what the organization has chosen; the Radar is how it chooses, how it retires choices, and how it keeps a domain-team organization from fragmenting. A senior engineer is expected to operate inside both.

The stack, layer by layer

Backend, data, and streaming

The backend layer is built on Kotlin, which gives the organization modern language ergonomics on the JVM, interop with the Java ecosystem, and coroutine-based concurrency that fits streaming workloads. The choice of Kotlin over plain Java is a bet on developer velocity and on coroutine structured concurrency for the high-concurrency fan-out that a real-time price pipeline needs.

The system of record for money and positions is PostgreSQL, chosen for its transactional guarantees, its mature operational story, and its rich indexing and partitioning. A ledger that must reconcile to the cent against an external custodian cannot live in an eventually-consistent store; it needs the strong, serializable transactions and the write-ahead log that Postgres provides. The interesting senior-level detail is that Postgres at brokerage scale stops being a boring database and becomes a tuning and partitioning problem: outbox tables bloat, statistics drift, and long transactions block vacuuming, so the database is treated as a first-class engineering surface, not a black box.

The diagram captures the central pattern: Postgres is the truth for state, Kafka is the system of motion that carries changes outward, and the two are bridged by change data capture on an outbox rather than by a dual-write. This is the stack’s answer to the dual-write problem, and it is a recurring interview signal.

Kafka is the streaming backbone, used both for event-driven integration between services and as the input to stateful stream processing. A real-time yield-to-maturity pipeline, for instance, consumes raw bond quotes from Kafka, computes the yield per instrument, and sinks results both to a Redis cache for immediate WebSocket delivery and to a topic for historical charts. Redis Cluster carries the real-time, hot-read workload, with sharded pub/sub so that fan-out scales rather than broadcasting every message to every node. Elasticsearch carries the search and recommendation workload that must return in tens of milliseconds.

Mobile, web, and search

The client story is mobile-first, and the clients are native, not cross-platform compromises. iOS is built in Swift and Android in Kotlin with Jetpack Compose, and both are first-class engineering functions with dedicated teams. The reason native matters is that a brokerage app lives and dies on perceived performance and on platform trust, and a cross-platform layer that adds latency or feels foreign on either platform erodes both. The web layer exists alongside the mobile clients, and visual regression testing guards the component libraries to prevent unintended UI regressions.

Search is its own surface. The instrument discovery experience is backed by Elasticsearch and is tuned to a strict latency budget, because the speed of finding the next investment is a conversion mechanism, not a vanity metric.

Platform, cloud, and security

The cloud platform is AWS, and the deployment substrate is Kubernetes, which carries both long-running services and batch jobs. Batch processing is horizontally scaled and partitioned rather than monolithic, because a single batch worker is a bottleneck and a single blast radius.

The security detail that matters most for a regulated business is the absence of long-lived static keys. Cloud resources are managed with OIDC-based short-lived credentials, so there is no stealable static key to compromise. The reasoning is direct: a static key is a credential class that can be exfiltrated and replayed, while a short-lived, identity-bound token expires before an attacker can use it. For a business that holds customer cash and securities, removing the stealable credential class is a baseline security posture, not an optimization.

Security as architecture, not decoration

In a regulated money business, the choice to eliminate static keys is not a security-team checkbox applied at the end. It is an architectural decision that shapes how every service authenticates to every resource. Senior engineers internalize that security properties are built into the stack, never bolted on.

The Tech Radar and how choices get governed

The stack above is not static, and it is not the private opinion of each team. It is governed by a Tech Radar, modeled on the ThoughtWorks format, that standardizes technology across the autonomous teams and is rendered as a living document.

Rings, quadrants, and the lifecycle of a choice

The Radar organizes technologies into four rings that describe their lifecycle stage, and four quadrants that describe their kind. The rings are assess, trial, adopt, and hold. A technology in assess is being explored for a possible future use; trial means it is in limited production use with growing confidence; adopt means it is the recommended default and new work should use it; hold means it is in use but should not be started in new work and is being phased out. The quadrants are languages-and-frameworks, devops, development tools, and techniques.

The value of the ring model is that it makes the lifecycle of a choice explicit. A technology is not simply “used” or “not used,” it sits at a stage of confidence, and the stage tells a team whether to build on it, to experiment with it, or to plan its removal. The Radar is a living document rendered in Backstage from per-blip markdown files, and engineering-function tags (backend, data, web, iOS, Android, SRE) filter relevance so a mobile engineer sees the blips that matter to them.

The lifecycle diagram is the governance story in miniature: choice is not a one-time event but a tracked progression, and retirement is as planned as adoption.

RFCs, the architecture forum, and autonomy with alignment

The Radar says what is chosen; the written-decision process says how a choice is made and recorded. Significant technical decisions are captured as RFCs and architecture decision records, and the significant ones go through an architecture forum of Senior and Senior-plus engineers. The combination is the mechanism that lets domain teams stay autonomous without fragmenting: a team can choose freely inside the adopt ring and experiment inside assess and trial, but a decision that changes the stack goes through a written, reviewed process that leaves a durable record.

The reason this matters at senior level is that the process is the work. A senior engineer does not just pick a technology, they write the decision, surface the tradeoffs, get it reviewed, and own the consequences. Tech choices are motivated by customer needs and the product, and tech leads enforce Radar upkeep, so the document does not rot. The autonomy-plus-alignment model is not a slogan, it is a daily discipline of written decisions and forum review.

The snippet’s point is that the stack choice is not a personal preference but a governed, recorded object: each technology is a Radar blip at a known ring, an experiment is explicitly bounded, and every decision points to its durable record. That is what keeps a domain-team organization from fragmenting into private technology islands.

Where the stack breaks at scale

Every layer of the stack has a scale at which its naive use fails, and a senior engineer is expected to name the failure and the response.

Postgres breaks on outbox and ledger volume. The outbox table that bridges Postgres to Kafka becomes a hotspot: a naive single table develops index bloat, its partial index on unpublished rows degrades, and a publisher that drains too many rows per batch opens a long transaction that blocks autovacuum. The senior response is a partitioned outbox, a partial index scoped to the unpublished partition, bounded batch sizes, and explicit autovacuum tuning. The ledger itself breaks on query planning when statistics drift, so statistics maintenance and partitioning become ongoing concerns, not one-time setup.

Kafka breaks on ordering and on the dual-write assumption. A team that assumes publishing to Kafka is part of a database transaction discovers phantom events. The stack’s answer is change data capture from the outbox, which makes the database the single source of truth and Kafka the consequence, never a co-equal writer.

Redis breaks on fan-out topology. Non-sharded pub/sub broadcasts every message to every node, which kills scalability. The senior answer is sharded pub/sub and a fan-out design where one backend subscription serves many WebSocket clients through a shared flow, with subscriptions created on demand and torn down when the last client leaves.

Kubernetes batch jobs break when treated as monolithic. A single large batch worker does not scale and fails as a unit. The senior answer is horizontally scaled, partitioned workers, which is the documented preference over monolithic ingestion.

Common mistakes candidates make

A few recurring mistakes reveal that a candidate has memorized the stack but not internalized its governance.

Quoting the stack without the why. A candidate lists Kotlin, Postgres, and Kafka but cannot say why each was chosen or what alternative it displaced. The interviewer hears a brochure, not a senior engineer.

Treating the Radar as decorative. A candidate describes the stack as fixed and ignores how choices evolve. The senior framing is that the Radar governs the lifecycle of every technology, and retirement is as planned as adoption.

Designing a dual-write because “we use Kafka.” A candidate writes a service that updates Postgres and publishes to Kafka in two steps. The documented failure mode is exactly this, and the stack’s own answer (change data capture from an outbox) is the fix a senior candidate names unprompted.

Assuming static cloud credentials. A candidate designs AWS access with long-lived keys. The senior answer eliminates the stealable credential class with OIDC short-lived tokens, because in a regulated business that is a baseline, not a nicety.

Ignoring Postgres operational depth. A candidate treats Postgres as a boring black box. At brokerage scale it is a tuning, partitioning, and statistics surface, and the candidate who shows no awareness of outbox bloat, index maintenance, or autovacuum reads as junior.

Mastery Questions

Question

Why does Trade Republic use a Tech Radar, and what problem does it solve that a domain-team organization would otherwise suffer?

Question

A service updates a Postgres balance and then publishes an event to Kafka. Why is this wrong given the stack's own design, and what replaces it?

Question

Explain the four Radar rings and what a team is allowed to do at each stage.

Question

Why does the cloud platform avoid long-lived static keys, and what is the senior-level reasoning?

Question

A real-time yield-to-maturity pipeline needs to fan updates to many WebSocket clients. Why is non-sharded Redis pub/sub the wrong choice?

Question

How does a technology move from assess to adopt, and what role do RFCs and the architecture forum play?

Question

Why is Postgres treated as a first-class engineering surface rather than a boring database at Trade Republic scale?

Answer

Roughly 280 engineers in autonomous domain teams could fragment into private technology islands with their own languages and datastores, making on-call, hiring, and security auditing intractable. The Radar provides explicit alignment without harming velocity: it standardizes technology across teams by placing each choice in a ring (assess, trial, adopt, hold) and a quadrant, rendered as a living document in Backstage with engineering-function tags. It resolves the autonomy-versus-alignment tension by making the lifecycle of every choice explicit, including its planned retirement.

Answer

Kafka does not participate in the Postgres transaction, so the two-step pattern is a dual-write: if the publish fails after commit, the balance changed with no event (a phantom state), and if the publish succeeds before commit and the commit fails, an event exists for a change that never happened. The stack's replacement is the outbox pattern: the event row is written in the same transaction as the balance, then change data capture (Debezium reading the WAL) streams the outbox to Kafka. Postgres stays the single source of truth; Kafka is the consequence.

Answer

Assess means the technology is being explored for possible future use, not yet in production. Trial means limited production use with growing confidence, suitable for bounded experiments. Adopt means it is the recommended default and new work should use it without special justification. Hold means it is in use but should not be started in new work and is being phased out. The rings make the confidence lifecycle explicit, so choice is a tracked progression rather than a binary used-or-not.

Answer

A static key is a stealable credential class that can be exfiltrated and replayed, which is unacceptable for a business holding customer cash and securities. The platform uses OIDC-based short-lived credentials bound to a workload identity, which expire before an attacker can reuse them. The senior reasoning is that this is an architectural decision shaping how every service authenticates, not a security checkbox applied late; removing the stealable class is a baseline posture for a regulated entity.

Answer

Non-sharded pub/sub broadcasts every message to every node in the cluster, so as message volume and node count grow, every node carries the full broadcast load and scalability collapses. The senior answer is Redis Cluster with sharded pub/sub, where messages go only to the shard owning the channel, plus a fan-out design where a single backend subscription per instrument serves many WebSocket clients through a shared flow. Subscriptions are created when the first client needs an instrument and torn down when the last client leaves, keeping the system lightweight.

Answer

A technology enters at assess for exploration, moves to trial for limited production use as confidence grows, and reaches adopt when proven as the recommended default. Movement between rings is not casual: significant decisions are written as RFCs and architecture decision records, and the significant ones go through an architecture forum of Senior and Senior-plus engineers. This written, reviewed process is what lets autonomous teams choose freely inside the adopt ring while preventing the stack from fragmenting, and it leaves a durable record so future engineers understand the why, not just the what.

Answer

At brokerage volume the system-of-record database stops being a black box. The outbox table that bridges to Kafka develops index bloat and its partial index on unpublished rows degrades; a publisher draining too many rows per batch opens a long transaction that blocks autovacuum. The ledger breaks on query planning when statistics drift. The senior response is a partitioned outbox, partial indexes scoped to the unpublished partition, bounded batch sizes, autovacuum tuning, and statistics maintenance. Treating Postgres as boring at this scale reads as junior.

Question

Why does Trade Republic use a Tech Radar, and what problem does it solve that a domain-team organization would otherwise suffer?

Answer

Roughly 280 engineers in autonomous domain teams could fragment into private technology islands with their own languages and datastores, making on-call, hiring, and security auditing intractable. The Radar provides explicit alignment without harming velocity: it standardizes technology across teams by placing each choice in a ring (assess, trial, adopt, hold) and a quadrant, rendered as a living document in Backstage with engineering-function tags. It resolves the autonomy-versus-alignment tension by making the lifecycle of every choice explicit, including its planned retirement.

Prev1 / 7Next