I built a real-time crypto trading platform. Here's what I learned the hard way. The problem: most trading demo projects fake real-time with polling. I wanted actual event-driven order execution — where a market event triggers a chain of services without any service directly calling another. The result: sub-100ms order acknowledgment latency with zero dropped events under concurrent load testing. The interesting decision: I chose Redis PubSub over WebSocket broadcasting for inter-service communication. WebSockets felt natural but created tight coupling — every service needed to know about every other. Redis as a message bus let each service be completely unaware of its consumers. When I added the notification service later, I plugged it in without touching a single existing service. That's when event-driven architecture stopped being a concept and became a tool I actually understood. I also had to design idempotent order handlers from scratch — when a Redis message gets redelivered after a crash, you cannot process the same order twice. Solved it with a Redis SET-based deduplication layer keyed on order UUID. What I'd do differently: I underestimated schema design for the order book. I normalized too aggressively early on and paid for it with expensive JOIN queries on the hot path. I'd denormalize the order state table from day one and use PostgreSQL LISTEN/NOTIFY instead of polling for order status updates. Full case study on my portfolio → my-portfolio-one-zeta-50.vercel.app