Binance processes up to 1.4 million transactions per second. Coinbase survived a Bitcoin rally in 2021 that pushed simultaneous user sessions up by more than 600% in under 48 hours. Most crypto exchange startups plan for their average day, not their best one. That’s where the architecture falls apart.

Handling high TPS isn’t about buying more servers. It’s about making the right architectural decisions before you have real load to test against. This guide walks through how a production exchange actually achieves scale — from matching engine design to database sharding, from Kafka event queues to cloud auto-scaling — and the decisions you need to make now, not after your first crash.

Why TPS Is the Wrong Metric to Start With

Most founders look at TPS and treat it as a single number to optimize. It isn’t. A crypto exchange has at least three throughput layers to worry about: order ingestion (how fast the API accepts incoming orders), matching throughput (how fast the engine processes them), and settlement throughput (how fast balances and trade records update in the database). Each layer has different bottlenecks.

We’ve seen teams build a matching engine that runs at 50,000 orders per second, then watch the whole system stall because the settlement layer could only write 2,000 database transactions per second. The fast engine just built a fast queue. The user still waited.

The number to track is end-to-end order execution time — from a trader hitting “buy” to the order being matched, confirmed, and reflected in their balance. For a retail exchange, under 50 milliseconds is acceptable. Institutional clients expect sub-5 milliseconds. The architecture decisions that get you from one to the other are fundamentally different.

Plan for three throughput tiers: MVP (500 to 1,000 TPS, handling up to 5,000 concurrent users), growth (10,000 to 50,000 TPS, $10 million to $50 million daily volume), and scale (100,000+ TPS, institutional-grade). Jumping straight from MVP to scale without planning the middle tier is one of the most expensive mistakes a startup makes. You’ll over-engineer the wrong parts and under-engineer the ones that matter.

The Matching Engine: Where Every Millisecond Costs You

The matching engine is the core of your exchange. It receives buy and sell orders and finds pairs. Simple in concept. The problem is doing it at speed without locking the order book.

The LMAX Disruptor pattern — developed for financial trading, now widely adopted in crypto — eliminates lock contention by running matching logic in a single thread with a ring buffer. Orders flow in, the engine processes them sequentially in memory, and events flow out. No mutexes. No waiting. This design handles over 100,000 orders per second on a single server with latency under 100 microseconds. One exchange we worked with switched from a mutex-based order book to a lock-free implementation. Match latency dropped from 8 milliseconds to under 400 microseconds overnight.

The rule: the matching engine never waits for a database. It runs entirely in memory, emits events — matched, unmatched, cancelled — to a message queue, and a separate persistence layer handles the write-to-disk work asynchronously. You’re not writing a trade to PostgreSQL directly. You’re emitting a TradeExecuted event into Kafka, and a consumer writes it. That separation is what keeps the engine fast.

For tech stack, Node.js works for your API layers and event consumers. But it’s a weak choice for the matching engine itself above roughly 8,000 concurrent order operations. Go or Rust matching engines are the practical standard for anything targeting 50,000+ TPS. Build the API in Node.js, write the matching engine in Go as a separate microservice, and connect them via Kafka topics.

If you want to go deeper on what institutional-grade matching engine design actually involves, this breakdown of trading engine architecture covers the full component model.

Kafka and the Event Bus That Actually Keeps Up

Apache Kafka is the backbone of most production-grade crypto exchange architectures. It handles communication between your matching engine, wallet service, notification system, compliance layer, and analytics pipeline — all without any of those services directly depending on each other.

A Kafka topic for order events handles north of 1 million messages per second on a well-configured cluster, with replication across 3 brokers for fault tolerance. At scale, partition your order topics by trading pair. BTC/USDT gets its own partition. ETH/USDT gets its own. This prevents high-volume pairs from blocking the low-volume ones.

One thing most architecture guides skip: Kafka’s “at least once” delivery guarantee means duplicate messages are possible. If your matching engine consumes a duplicate PlaceOrder event and processes it twice, a user ends up with two open positions instead of one. You need idempotency keys on every order event. This is not optional. One team skipped it in their MVP. They processed $80,000 in duplicate trades before the bug surfaced in production — and untangling it took six weeks.

RabbitMQ is a valid alternative for smaller setups. It’s simpler to configure and handles up to about 50,000 messages per second without issue. Beyond that, Kafka is the right tool. The configuration overhead pays for itself quickly once you’re past early growth.

Database Architecture: Why SQL Alone Breaks at Scale

A single PostgreSQL instance handles a small exchange comfortably — maybe 5,000 write transactions per second before you start feeling it. Beyond that, you need a real plan.

Most modern exchanges run a split model. PostgreSQL or MySQL handles transactional data — trades, user balances, orders — where ACID compliance matters. Redis handles caching: order book snapshots, session tokens, rate limit counters. It returns data in under 1 millisecond, versus 5 to 20 milliseconds for a typical database query. At 50,000 API requests per second, those extra 19 milliseconds compound fast. A time-series database like TimescaleDB or InfluxDB handles market data, candlestick history, and trade analytics.

Database sharding splits your data horizontally. User records split by user ID range. Orders split by trading pair or time window. Multiple database nodes run in parallel, each handling a slice of total traffic. The tradeoff: cross-shard queries get complicated fast. If a trade involves two users sitting on different shards, your application logic handles the coordination. Teams consistently underestimate this complexity. Plan it into your schema before you need it, not after.

Read replicas separate reporting and analytics traffic from your transactional primary. Your primary database should only handle writes and critical reads. Everything else — trade history, user dashboards, admin reporting — hits a replica. At $10 million in daily volume you probably don’t need this yet. At $50 million, you will, and retrofitting it is painful.

Horizontal vs Vertical Scaling — When Each Makes Sense

Vertical scaling adds more CPU and RAM to one server. Horizontal scaling adds more servers. The right answer depends on which service you’re scaling.

For the matching engine: go vertical first. A single powerful server running an in-memory engine is faster than distributing it across nodes, because distributed matching requires coordination that adds latency. A bare-metal or dedicated cloud instance with 64-core CPU and 512GB RAM runs about $4,000 to $6,000 per month and handles 500,000+ matching operations per second without sharding the order book.

For everything else — APIs, wallet services, KYC workers, notification services — go horizontal. These services are stateless or near-stateless. Running 10 Node.js API pods behind an NGINX or AWS ALB load balancer is cheaper and more resilient than one massive API server. If a pod crashes, 9 others keep serving traffic. Kubernetes makes this straightforward: set a CPU utilization threshold of 60 to 70%, and it automatically adds pods when you approach that ceiling.

The mistake founders make is trying to horizontally scale the matching engine before exhausting vertical options. Splitting an order book across nodes requires distributed consensus on order priority. That coordination overhead costs you more latency than you gain in compute. Go vertical on the engine. Go horizontal on everything around it.

Auto-Scaling Infrastructure: What Coinbase Got Right

During the 2021 Bitcoin rally, Coinbase went from roughly 1 million to over 6 million daily active users in under 48 hours. They survived because they’d built their infrastructure on AWS with auto-scaling groups configured to treat traffic spikes as the normal case, not the edge case.

The key decisions: containerize every service with Docker, deploy on Kubernetes, and configure horizontal pod autoscalers on CPU and requests-per-second metrics. Set scale-out triggers at 60% CPU, not 90%. By the time you hit 90%, new pods take 30 to 90 seconds to initialize, and users are already getting errors. Set your trigger early and accept the slightly higher idle cost. It’s much cheaper than a 30-minute outage during peak volume.

On AWS, a starting production setup — 3 API pods on EKS, managed Redis via ElastiCache, RDS PostgreSQL with one read replica, and Kafka via MSK — runs $8,000 to $15,000 per month. Add a dedicated matching engine instance and you’re at $20,000 to $30,000. Cloudflare Enterprise DDoS protection adds another $3,000 to $5,000. Google Cloud and Azure are within about 10% of those numbers.

That math doesn’t work on a bootstrap budget, which is why most early exchanges start on a $500 to $1,500 per month VPS setup and migrate to cloud-native infrastructure at growth stage. That migration is painful but manageable if your services are containerized from day one. Don’t run monolithic code on a single server and expect a clean cloud migration later. It won’t be clean.

The Cold-Start Liquidity Problem No One Talks About

High throughput is meaningless without orders to process. A new exchange that can handle 1 million TPS but has 12 users placing 3 orders per day isn’t a performance problem. It’s a liquidity problem wearing performance clothes.

The cold-start loop: your order book is empty, so spreads are wide, so traders get bad fills, so they leave, so the book stays empty. You need market makers on day one — not month three.

The practical fix: market maker incentive programs. Offer makers a rebate of 0.01% to 0.02% on filled orders when they’re quoting inside the spread. Binance and Kraken both built their early liquidity depth this way. You can also use liquidity aggregation — pulling order flow from a larger upstream exchange via API and mirroring it on your own book. This gives new users apparent depth while you build organic volume. It’s legal in most jurisdictions, but check compliance counsel before launching in EU markets regulated under MiCA.

The infrastructure implication: if you’re routing aggregated external liquidity, your API latency to upstream exchanges must stay under 50 milliseconds. That means co-location or a datacenter close to Binance’s primary infrastructure in Tokyo or AWS us-east-1 in Virginia. Co-location slots run $5,000 to $15,000 per month depending on rack space and bandwidth. It sounds expensive. A wide spread on day one is more expensive.

CEX vs DEX vs Hybrid: Which Architecture Scales in 2026

Centralized exchanges still dominate high-TPS scenarios. On-chain matching on Ethereum processes about 15 transactions per second at peak — essentially unusable for a trading platform. Solana reaches 65,000 theoretical TPS, but real-world trading conditions sustained under 3,000 TPS in most 2025 benchmarks. On-chain alone doesn’t compete with a well-built CEX.

Off-chain order matching with on-chain settlement — the hybrid model — is where most serious new exchanges are landing in 2026. Users deposit funds on-chain. The exchange matches orders in its internal engine off-chain, fast. Settlement batches back to the chain every few seconds or on withdrawal. You get CEX-level matching speed with non-custodial fund security. dYdX v4 uses this approach. Hyperliquid does too, and it processed over $10 billion in monthly volume by early 2026.

For founders choosing architecture now: if you’re targeting retail trading with high volume, build a CEX with off-chain matching. If you’re building DeFi-native with composability requirements, build hybrid. Pure on-chain AMMs scale differently — throughput is capped by blockchain TPS, but there’s no matching engine to maintain and no custody of user funds. The regulatory and security surface area is smaller, but slippage at depth is a problem that order books consistently solve better.

The model you pick has a 3-to-5 year architectural commitment. Choose based on your user type, not the hype cycle.

Frequently Asked Questions

What TPS do I need for a crypto exchange MVP?

500 to 1,000 TPS is enough for an MVP handling up to 5,000 concurrent users. A single-server setup with an in-memory matching engine, Redis caching, and PostgreSQL handles this for $1,500 to $3,000 per month. You won’t need Kafka partitioning or database sharding at this stage — but design your services as if you will, so the migration is clean when you need it.

Can Node.js handle a high-TPS matching engine?

For the API layer and event consumers, yes. For the matching engine itself at high load, no. The event loop becomes a bottleneck above roughly 8,000 concurrent order operations. Go or Rust matching engines are the practical standard for anything targeting 50,000+ TPS. Build the API in Node.js, write the matching core in Go as a separate microservice, and connect them via Kafka topics.

How does Redis improve exchange performance?

Redis stores frequently accessed data in memory — order book snapshots, session tokens, rate limit counters, recent price ticks. A single Redis node returns data in under 1 millisecond versus 5 to 20 milliseconds for a standard database query. At 50,000 API requests per second, that gap is the difference between a smooth trading experience and a lagging UI. Most production exchanges deploy Redis Cluster with replication across 3 nodes for fault tolerance.

What’s the difference between database sharding and read replicas?

Sharding splits data horizontally across multiple nodes — users A to M on one shard, N to Z on another — and increases write capacity. Read replicas copy your primary to secondary nodes that only handle SELECT queries, increasing read capacity. You’ll typically need read replicas first (around $5 million daily volume) and sharding later (around $50 million). Both solve different bottlenecks and most mature exchanges use both.

What causes crypto exchanges to crash during Bitcoin rallies?

Three repeating causes: API endpoints with no request throttling that accept unlimited inbound connections, a matching engine that waits for a database write before processing the next order, and no auto-scaling configured for the API layer. Coinbase hit all three in 2018. Their 2021 survival came from fixing each one systematically. If your matching engine depends on a database confirmation before emitting a match, your crash is already scheduled.

How much does production-grade exchange infrastructure cost?

A baseline production setup on AWS — EKS, RDS PostgreSQL with read replica, ElastiCache Redis cluster, Kafka on MSK, and a dedicated matching engine server — runs $20,000 to $35,000 per month. Add Cloudflare Enterprise DDoS protection at $3,000 to $5,000. Co-location for HFT clients adds another $5,000 to $15,000 depending on datacenter and bandwidth commitment.

Do I need MiCA compliance if I’m targeting EU users?

Yes, regardless of where your company is registered. Under MiCA, any exchange providing crypto-asset services to EU users must be authorized as a Crypto-Asset Service Provider (CASP) if it holds custody of user funds. KYC and AML checks must run in real time for new accounts and for transactions above €1,000. Build compliance as a standalone microservice from the start — a monolithic compliance check inside your API layer becomes a performance bottleneck during high-traffic onboarding events.