What to Expect in the RBC System Design Interview

Expect a design discussion built on RBC's own problems: payments, transactions, client data, and migrations without downtime. RBC is Royal Bank of Canada, and its interviewers ask about the systems the bank actually runs. Candidates report questions about high throughput transaction handling, payment processing, data consistency across distributed databases, and securing APIs that carry sensitive data.

Candidates also report questions about moving a legacy monolithic backend to microservices with no service interruption. The round usually lasts 45 to 60 minutes, inside a technical interview or a panel, and correctness is graded more heavily than raw throughput.

The Question Types

Payments and transaction processing is the most reported area, and candidates describe designing an end to end payment processing service for high peak volumes. Another reported question asks for a high throughput transaction scheduling system. The hard parts in both are duplicate charges, strict ordering, and recovery after a crash.

Data consistency across services is next, with reported questions on keeping data consistent across distributed databases in a financial application. Distributed means the data is stored on several machines at once. Expect to discuss what you keep strictly consistent and what you allow to become consistent a moment later.

Database choice and uptime come up together: which store fits the access patterns, and how the service stays available during maintenance. Candidates also report a question about a real time notification service for mobile and web banking clients. State your access patterns first, then pick the store, then justify that choice against one alternative.

API security for sensitive data is reported too, usually securing REST APIs that carry client information. A REST API is an interface in which each request names a resource over HTTP. Cover authentication, authorization per field, encryption, and logging detailed enough to support an audit.

Performance repair appears as a question about fixing a microservice architecture that slows under peak traffic, and it is a measurement question first, so say how you would find the slow part before changing anything.

Capital markets systems come up for trading roles. Candidates report an order management system, and a service that consumes a market data feed and keeps live positions. Interviewers there reward exact ordering guarantees and safe recovery more than clever sharding.

What the Interviewer Grades

Practical judgment counts more than an exotic diagram, so state the requirements and failure cases first. Name every trade-off out loud, then say which option you chose and why. Connect each choice to money and to the client, because a duplicate payment is a real loss. Regulatory and audit needs belong in your first pass, and interviewers also listen for whether you could operate the system, so include monitoring and alerts.

A Walkthrough: Design a Payment Processing Service

1. Requirements (about 5 minutes). Clarify the payment types, the peak volume per second, and the latency clients accept. Confirm the hard rule as well: no payment is ever applied twice, and no payment is silently lost.

2. The request path. An API gateway authenticates the caller and applies rate limits, where a gateway is one service through which every request passes. The payment service then validates the request and writes it to a durable store before any money moves.

3. Idempotency. Idempotency means that repeating the same request produces the same single result. Require a client supplied key on every payment request, store that key with its result, and return the stored result on a repeat, which answers the retry question and the duplicate question together.

4. Asynchronous settlement. Put accepted payments on a durable queue and process them with workers, since such a queue keeps each message safely until a worker confirms completion. Use one partition per account, so that two payments for the same account never run out of order.

5. Consistency and the ledger. Keep the ledger of account balances strictly consistent inside one database transaction, where a ledger is the authoritative record of every movement of money. Let reporting and notification services update later, because those readers tolerate a delay of a few seconds.

6. Reconciliation and failure. Reconciliation means comparing your records against the other party's records and fixing the differences. Run it on a schedule against the payment network, and keep an exception queue for mismatches. After a crash, workers resume from the queue, and the idempotency keys prevent any double effect.

7. Audit and controls. Log every request, decision, and state change with the actor and the time, keep personal data encrypted, and limit which fields each service can read.

8. Scale and migration. Shard by account, cache reference data, and refuse low priority requests during a spike. If the question involves a legacy system, describe a parallel run: send traffic to both, compare results, then shift traffic gradually.

Common Mistakes in This Round

• Skipping idempotency. In a banking design, a duplicate payment is the first failure tested, so raise it before you are asked.
• Choosing eventual consistency for balances. Reports and alerts can update later, but the balance a client sees and spends cannot.
• Leaving out audit and access control. A bank cannot operate a service that nobody can review afterwards.
• No migration plan. Reported questions name legacy systems directly, so practice describing a cutover with no downtime.
• Designing without numbers. Estimate the peak rate and the storage growth first, then size each part from those estimates.

How to Prepare

• Learn the building blocks first. Grokking the System Design Interview covers queues, caches, sharding, and replication, which every banking answer uses.
• Go deeper on consistency. Advanced System Design Interview, Volume II covers transactions, isolation levels, and failure recovery.
• Rehearse the payment walkthrough. Practice the eight steps above out loud, and finish them in under 40 minutes.
• See where this round sits. The design discussion is one part of the RBC interview process, next to the motivation question and the wait described in how long it takes to hear back.