Building an Exchange with Claude Code (2)

February 13, 2026 3 minute read

Continuing from the last post…

Well, it’s more or less done.

There’s no need to build it out any further so I’m stopping here, but order matching and futures position liquidation are implemented,

and the TPS looks good. Push it much further and I think my computer goes to heaven first…

System architecture

    [User browser] → [CloudFront/S3] → [ALB] → [API Gateway :8080]
                                                          │
                        ┌──────────────────────────────────┼──────────────────────────┐
                        │                                  │                          │
                  [UCenter :6001]                  [Exchange API :6004]        [Market :6003]
                  (members/auth/KYC)               (spot trading API)          (quotes/WebSocket)
                        │                                  │                          │
                  [OTC API :6002]                [Exchange Engine :6005]      [Futures API :6009]
                  (P2P trading)                   (order matching engine)     (futures trading API)
                        │                                  │                          │
                  [Wallet :6006]                [Futures Engine :6008]         [Chat :6007]
                  (deposits/withdrawals)         (futures matching engine)     (messaging)
                        │                                  │                          │
                  [Admin :6010]                   [Robot :20000]               [Redis 7]
                  (admin API)              (market-making bot — tracks Binance)  (cache/session)
                        │                                  │                          │
                        └──────────────[MySQL 8.0]─────────┼────[MongoDB 7.0]─────────┘
                                                           │
                                                      [Kafka 3.6]
                                                   (event streaming)

Core features

Trading covers spot trading (live order book + candlestick charts), futures trading (with leverage), OTC P2P fiat trading (escrow), and an automated market-making bot that tracks quotes from Binance/OKX/HTX.

User features include email/SMS-verified signup, KYC identity verification (ID upload), 2FA, multi-currency wallets (deposits/withdrawals), and a referral system with commission tracking.

Admin features span 60+ management pages: member management, the KYC approval workflow, trading-pair and coin configuration, order monitoring, financial reports, and bot control.

Now, supposing you deployed this to AWS with Terraform…

Performance analysis: users supported per configuration

I analyzed where this system bottlenecks and estimated how many users each server configuration could support.

Bottleneck analysis

Area	Bottleneck	Impact
Matching engine	Single-threaded `synchronized` processing per symbol	Caps throughput for a single trading pair
Gateway	Redis rate limiter + connection pool	Caps concurrent connections
Kafka	Broker count × partition count	Caps message throughput
MySQL	Connection pool (HikariCP max 50) + I/O	Bottleneck on persisting orders/fills
WebSocket	Market service memory + network bandwidth	Caps live-quote subscriber count

Estimated performance by configuration

Tier 1: Staging / development (~$410/mo)

Component	Spec
ECS Fargate	0.5 vCPU / 1GB RAM per service (12 services)
MySQL	db.t3.micro (2 vCPU, 1GB)
Redis	cache.t3.micro
Kafka	kafka.t3.small × 2 brokers
MongoDB	t3.micro EC2

Metric	Value
Concurrent users	300 – 500
Order throughput	~200/sec (single trading pair)
WebSocket subscribers	~1,000
Order book depth	100 levels
API response time	50–200ms (p95)
Daily active users	~2,000

Tier 2: Small production (~$1,200/mo)

Component	Spec
ECS Fargate	1 vCPU / 2GB RAM per service
MySQL	db.t3.medium (2 vCPU, 4GB)
Redis	cache.t3.small
Kafka	kafka.m5.large × 2 brokers
MongoDB	t3.small EC2

Metric	Value
Concurrent users	1,000 – 3,000
Order throughput	~800/sec (single trading pair)
WebSocket subscribers	~5,000
Order book depth	100 levels
API response time	20–100ms (p95)
Daily active users	~10,000

Tier 3: Mid-size production (~$3,500/mo)

Component	Spec
ECS Fargate	Engines 2 vCPU / 4GB, API services 1 vCPU / 2GB (Multi-AZ)
MySQL	db.r6g.large (2 vCPU, 16GB) + 1 read replica
Redis	cache.r6g.large (cluster mode)
Kafka	kafka.m5.large × 3 brokers
MongoDB	r6g.large EC2

Metric	Value
Concurrent users	5,000 – 15,000
Order throughput	~3,000/sec (single trading pair)
WebSocket subscribers	~20,000
Order book depth	100 levels
API response time	10–50ms (p95)
Daily active users	~50,000

Tier 4: Large production (~$8,000+/mo)

Component	Spec
ECS Fargate	Engines 4 vCPU / 8GB, API 2 vCPU / 4GB (3-AZ)
MySQL	db.r6g.xlarge (4 vCPU, 32GB) + 2 read replicas
Redis	cache.r6g.xlarge (cluster mode, 3 shards)
Kafka	kafka.m5.2xlarge × 3 brokers
MongoDB	r6g.xlarge EC2 (replica set)

Metric	Value
Concurrent users	20,000 – 50,000
Order throughput	~8,000/sec (single trading pair)
WebSocket subscribers	~80,000
Order book depth	100 levels
API response time	5–30ms (p95)
Daily active users	~200,000

Summary comparison

Item	Tier 1 (staging)	Tier 2 (small)	Tier 3 (mid)	Tier 4 (large)
Monthly cost	~$410	~$1,200	~$3,500	~$8,000+
Concurrent	300–500	1K–3K	5K–15K	20K–50K
Orders/sec	~200	~800	~3,000	~8,000
DAU	~2K	~10K	~50K	~200K
Suited for	Dev/test	Small launch	Mid-size exchange	Large exchange

Note: These figures are theoretical estimates based on the code structure, data-structure characteristics, and infrastructure specs. Real performance varies with the number of trading pairs, order patterns, and network conditions, and you must run load tests before deploying to production. The project includes a load-testing framework (loadtest/) that simulates 1,000 concurrent users.

There’s just no end to it, haha.

Enjoy your AI life, everyone!

Michael Kim (김완기)