What to Expect in the Kalshi System Design Interview

Expect a standard system design round shaped by an exchange. A candidate on Blind describes "standard system design" as part of the Kalshi process. Kalshi runs a regulated exchange for event contracts, where an event contract pays out based on whether a real world event happens.

Kalshi's backend job descriptions name order matching, trade execution, market data feeds, and clearing, which are the systems a design question will most likely follow. Kalshi does not publish an interview guide, so the topics below are inferred from the product, not reported by candidates.

The Question Types

The order book and matching engine. An order book is the list of open buy and sell orders for one contract, and a matching engine pairs a new order with the best resting orders on the other side. The hard parts are ordering, fairness, and speed under load, because every order must be processed exactly once, in the order it arrived.

The market data feed. Traders need to see the order book change in real time, so Kalshi offers a WebSocket feed, which is a long-lived connection that pushes updates to a client. The design question is how to fan out one change to many thousands of clients without lag.

Clearing and settlement. Clearing moves money between the two sides after a trade, while settlement pays the winners when an event resolves. The hard parts are correctness and the audit trail, because a double payout or a lost cent is a serious defect on a regulated exchange.

Risk and collateral checks. Before an order enters the book, the system must confirm the trader can pay for it, and this check must be fast and must never be wrong. Expect questions about locking and transactions, including the case where two orders arrive at once and both need the same balance.

Standard building blocks. Kalshi's job descriptions ask for strong relational database and transaction knowledge, plus experience with highly concurrent systems, so expect questions about database access patterns, caching, and queues.

What the Interviewer Grades

Correctness comes before scale in a financial system, so state the invariants first, where an invariant is a rule that must always be true, such as "no trader's balance goes below zero."

Name your trade-offs out loud, and connect each choice to money, because a wrong match costs real dollars. One Blind reply says the small team judges candidates on the need for their background, so show depth in one area.

A Walkthrough: Design a Prediction Market Exchange

Here is a high level plan for the signature question.

1. Requirements (5 minutes). Many markets, each with a yes side and a no side, with limit orders and market orders. Balances must be exact, the book must be visible to all traders in near real time, and every trade must be auditable later.

2. The order path. An order arrives at an API gateway, which checks authentication and rate limits, and then a risk service checks that the trader has collateral for the order. Collateral is the money set aside to cover a possible loss, and once the check passes, the order goes to the matching engine for that market.

3. The matching engine. Keep one single-threaded matcher per market, which removes locks and makes ordering simple, and store the book in memory with price levels sorted and a queue of orders at each level. Match against the best price first, then the earliest order at that price, and write every event to an append-only log before acknowledging the order.

4. Persistence and recovery. The append-only log is the source of truth, while a database stores balances and positions inside transactions. If the matcher restarts, it rebuilds the book by replaying the log, and snapshots make the replay short.

5. The market data feed. The matcher publishes each book change to a message bus, and a set of feed servers subscribes and pushes updates over WebSockets. A client that has missed updates receives a fresh snapshot, not a growing backlog.

6. Settlement. When an event resolves, a settlement job reads the final positions per trader, credits winners and debits losers in one transaction per trader, and writes a settlement record for the audit trail. It retries safely, so running it twice never pays twice.

7. Scale and failure. Add markets by adding matchers, since each market is independent, and replicate the log across machines. Fail over a matcher only after the log is durable, and alert on any balance check that fails.

Common Mistakes in This Round

• Starting with scale. A correct book for one market comes first, because sharding a wrong design does not fix it.
• Ignoring money invariants. Skipping the collateral check, or letting balances go negative, is a serious miss.
• No audit story. A regulated exchange must explain every trade later, so say where the log lives and how it is protected.
• Multi-threading the matcher. Locks inside a matcher cause ordering bugs, so one thread per market is the common answer, and interviewers expect you to know why.
• Forgetting the slow client. A market data feed must survive clients that read updates too slowly.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and databases, which every exchange design uses.
• Study failure handling further. Advanced System Design Interview, Volume II helps with replication, logs, and recovery.
• Rehearse the exchange walkthrough. Practice the seven steps above out loud in under 40 minutes.
• See the full loop. The design round is one stage of the Kalshi interview process, next to the motivation question and the waiting period after the loop.