Investo

NextjsRedisNodePostgres

Real-time Order Matching Engine with Live Candelstick Data

Investo simulates the core infrastructure of a real stock exchange — from order placement to trade execution. The platform runs a custom matching engine that pairs buy and sell orders using price-time priority, just like production exchanges. Two markets run live with dedicated market makers continuously adding liquidity, so there's always action in the orderbook.

Built for anyone who wants to see what happens behind the trade button — real-time WebSocket feeds push orderbook depth and price updates to the UI the moment a match happens, while candlestick charts aggregate live trade data to show market momentum as it forms.

System Architecture

Investo/How it works

A real-time stock exchange simulator. Each service in the pipeline is responsible for exactly one thing.

Client / APIRedis pub/subEngineWS pathDB pathDatabaseBackground

Built with WebSockets · Redis pub/sub · Prisma · Docker · Node.js

Investo / Scaling Guide

How to Scale
the Exchange

Six concrete problems in the current Investo architecture — what breaks, why it breaks, and exactly how to fix each one. Ordered by risk.

Critical issues

High issues

Total fixes

Your Node.js matching engine is single-threaded. One process holds all 100 orderbooks in memory. As order volume grows, the event loop maxes out — every market stalls together because they all share one CPU core.

Current state — broken

API Server

↓

Engine (Node.js)

100 orderbooks — CPU 100% 🔴

BOTTLENECK

TATAPAYTMZOMATORELIANCEHDFCSBITCSINFYWIPRO...×91

End state

Full Scaled Architecture

All six fixes applied together

API Pod 1

API Pod 2

API Pod 3

reads shard_map from Redis ↓

Redis — shard_map + per-request replyTo channels + Streams

Shard A (Rust)

Primary A1

→

Replica A2

markets 1–50

Shard B (Rust)

Primary B1

→

Replica B2

markets 51–100

WS Pods (×3)
fans out to browsers

DB Workers (×2)
Redis Streams

Postgres + Prisma
source of truth

Implementation Priority

1Per-request response channelscorrectness issue, not just scale

2Switch DB Worker to Redis Streamsactive data loss risk

3Orderbook rebuild on engine startupcrash durability

4Engine sharding by markethorizontal throughput scale

5Multiple WS client podsconnection scale + availability

6Rust matching engine10× throughput, delay sharding further

Investo · Scaling Guide · WebSockets · Redis · Rust · Prisma · Docker

Security Threat Model

Insider Threats
in Investo

The most dangerous attacker already has your credentials. These are the five attacks that matter most — and how to stop them.

3

Critical

2

High

5

Total

Developer with engine access modifies a user's in-memory balance directly. The withdrawal service trusts the engine's memory as source of truth — so the inflated balance passes the check and money leaves.

Step by step

1Access running engine process (prod SSH or kubectl exec)

2Modify in-memory: user[42].balance = 10_000_000

3Trigger withdrawal — engine says ₹1cr available

4Withdrawal approved. Engine restarts. Memory wiped. No trace.

Five Things That Actually Matter

If you implement only these, you're ahead of most fintech startups

🔐

Never trust one engine's memory

In-memory state can be modified by anyone with server access. Multi-region quorum consensus means a single compromised engine cannot influence withdrawals or balances.

✍️

Sign everything at the client

Private keys that never leave the browser make server-side impersonation impossible. No signature = no order processed, regardless of who sends it or how.

👁

Run a canary you don't control

A shadow engine owned by a separate team and comparing every match output is the only reliable way to catch algorithmic manipulation that leaves no other trace.

🏛

Asymmetric keys for all trust boundaries

JWT secrets, event signing, and auth tokens should all use asymmetric cryptography. A public key cannot forge — only verify. Secrets that live in .env files will eventually leak.

📜

Immutable audit logs you cannot delete

Every control above can be bypassed by someone who can also delete the logs. Logs must be append-only, cryptographically chained, and shipped to a system no single developer can access.

The principle behind all of it

"Verify everything.
Trust nothing implicitly."

Zero Trust Architecture · Investo Security Model

Investo · Threat Model · ECDSA · Quorum · HSM · Kafka · Canary Engine

Live Preview