Backend / Distributed Systems
Algorithmic Trading Platform
Event-driven order processing over Kafka, built for correctness under concurrency.
Problem
Trading systems are a useful backend design problem because correctness matters more than almost anywhere else: orders must be processed in the right order, state must stay consistent under concurrent access, and failures have to be handled explicitly rather than silently swallowed. This project explores that problem space — service boundaries, event-driven communication, and the reliability concerns that come with it.
Architecture
Order intake is decoupled from order processing via Kafka, so the API layer stays responsive under load while downstream consumers process events at their own pace. Redis sits alongside the database for state that needs low-latency access.
Hover or tab through a node to see what it does.
What it does
- Service boundaries separating order intake, processing, and notification concerns
- Kafka-based event streaming to decouple producers from consumers
- Redis used for low-latency state alongside persistent storage
- Concurrency-aware handling of order state
- REST API layer for client and gateway interaction
- Monitoring hooks for tracking service health
Engineering decisions
Kafka for order events rather than direct service calls
Decoupling producers and consumers means the intake path isn't blocked by downstream processing time, and consumers can be scaled or restarted independently.
Redis for hot-path state
Frequently-read state that doesn't need full relational guarantees is kept in Redis to reduce database load and latency.
Scope note
This is a systems-design and implementation project, not a production trading business. No real financial metrics, transaction volumes, or client data exist for this project, and none are claimed here.