Jan 2024/Backend/course
openMusic API
The fastest way to destroy a music streaming API is to make a user wait for a CSV export to finish before their playlist loads. I built openMusic API to solve this by treating service decomposition as a first-class design constraint, not an afterthought.
The architecture is split into two distinct services. The main Hapi.js backend handles all latency-sensitive requests: song catalog, user authentication, album uploads, and playlist collaboration. Any heavy background work like data exports gets pushed directly into a RabbitMQ queue. A completely separate consumer service picks those jobs up and processes them asynchronously, leaving the API path untouched.
The biggest takeaway is that Redis and RabbitMQ solve fundamentally different problems. Redis absorbs repetitive read traffic so the database stays fast. RabbitMQ decouples heavy work from user-facing requests so the API stays responsive. Understanding the distinction between caching and queueing is what separates a backend that scales from one that eventually collapses under its own load.