BRDG
A cross-chain bridge aggregator. One request quotes every bridge that can serve a route, ranks them by what actually arrives, and follows the transfer until it lands. About 35 bridges across 73 chains.
TypeScript · Hono · Postgres · Redis
Erzum Shirazi · Toronto
Erzum Shirazi. I build systems that stay fast and stay correct under load.
Software engineer and CS student at TMU (graduating December 2027), currently at Print.World working in Rust and TypeScript on real-time backend systems. Previously IBM and Nokia. I care about performance, reliability, and the trade-offs between them.
01About
Hi, I'm Erzum.
I'm a software engineer in Toronto who likes building systems where performance and correctness both matter: backends that stay fast under load, data pipelines that don't lose events, and services other engineers are happy to depend on.
I started with C++ on a high-throughput packet-inspection test harness at Nokia, then spent sixteen months at IBM on CI/CD, an inner-source Go SDK, and Watson's request path, including a code review service that became its own product. Today I'm at Print.World, working in Rust and TypeScript on a trading platform's backend: real-time market data, caching, websockets, and BRDG, a cross-chain aggregator I built.
Outside of work I build things to understand them: a real-time ML pipeline serving quantized models on my own GPUs, low-latency transaction sending on Solana, and a systematic trading system I research and run. I study computer science with a finance minor at TMU.
- Based in
- Toronto
- Studying
- Computer Science, Minor in Finance, TMU
- Currently
- Software Engineer, Print.World
- Languages
- TypeScript, Rust, Python, Go, C++
- Interested in
- Distributed systems, performance, data infrastructure, ML serving, trading systems
02Timeline
Where I've been, and what I built there.
Each chapter opens up. The short version is what I did; the linked posts are the longer story of how I thought it through.
Print.World is a crypto trading terminal. I work on the trading engine the terminal sits on, and I built BRDG, our cross-chain bridge aggregator. I do this alongside finishing my degree.
- Worked on the trading engine the terminal sits on: quotes, routing, and execution
- Built a stress harness for the Rust market-data processor and removed a global lock: throughput up 33%, p99 from 139ms to 40ms in the harness
- Built BRDG: quotes about 35 bridges across 73 chains, ranks them by what actually arrives, and tracks every transfer to completion
- Built a perpetual futures aggregator merging 21 venues into one order book, with depth-walking routing and idempotent order placement
- Moved trade and candle history from TimescaleDB to ClickHouse: dual-write, windowed backfill, and exact parity across 9.59M bars before cutover
- Made the call to stream perps books through Centrifugo with sequenced deltas, behind a live switch with a fallback
03Selected projects
Things I've built.
A few highlights. The full list, with the stack I work in, is on the work page.
Real-time inference
Fine-tuned, quantized vision-language models on two GPUs scoring a live feed, with separate text and media lanes and a tail latency I had to go and find.
Python · llama.cpp · AMD GPUs
Solana trade path
Swap building across the main DEX families, a cache that checks itself against the chain, and a per-trade latency breakdown. Built at Print.World.
Rust · tokio · Redis · Kafka
Perps aggregation
One order book built from 21 perpetual futures venues, a depth-walking router, and idempotent order placement. Built at Print.World.
TypeScript · Redis · WebSockets
pump.fun launch pipeline
Posts from tracked X accounts, delivered about 200ms after posting, turned into pump.fun token launches automatically: atomic bundles, multi-relay sending, and a per-stage latency budget.
TypeScript · Redis · Rust
My own book
A six-figure systematic book on crypto perpetual futures: a trend core, small event trades including an oil spread, and a risk ladder built from a drawdown budget.
Python · Hyperliquid
04Explore
Explore
05Selected writing
Selected writing
- ClickHouse or RocksDB?When our trade and candle history outgrew TimescaleDB, ClickHouse looked like the obvious next step. I argued the case for RocksDB anyway, to make sure "obvious" meant "right". Here's how the comparison came out.
- Taking the lock off the hot pathBuilding a stress harness for our Rust market-data processor, finding a global mutex hiding behind a cache, and what changed when I replaced it. Throughput up a third, p99 down from 139ms to 40ms.
- Fix our websocket server, or adopt one?Our in-house websocket layer was struggling with live perps order books. The bounded fixes looked cheap, adopting Centrifugo looked expensive, and the decision came down to which one I'd still trust in six months.
- Designing for the retryAny code that moves money will eventually run twice. The design rules I use so that "twice" is always harmless, with the state machines and diagrams behind them.
- Sixteen months at IBMCI/CD for Watson, then telemetry, then building Watson Code Review, an LLM review service on RabbitMQ and OpenShift. KV caching, when to re-run a review, how results reach developers, and how it scaled.