IDCamp 2024/Backend/course

openMusic API

Built in the IDCamp 2024 backend JavaScript track, this project highlights system design by keeping export, auth, cache, collaboration, and upload concerns in separate boundaries.

project links

Repositoryrepo

Domain

Backend

Role

Backend Engineer

Output

Backend API

A source-backed case study built for recruiter review

This reading path makes the problem choice, evidence quality, user framing, execution decisions, and proof trail visible without overstating what the sources support.

Project Type

course

Backend API project that separates main request handling from background export work through an API service and queue consumer.

Orientation

Tech

Demonstrates scalable backend thinking through modular service boundaries and safer handling of long-running export work.

Core Stack

Node.js · Hapi.js · PostgreSQL · Redis

Hapi-based backend API paired with a queue consumer for background jobs, using PostgreSQL for persistent data, Redis for cache-oriented concerns, RabbitMQ for queueing, and JWT for access control.

Why This Problem Mattered

Problem framing before execution

The case-study layer starts with why this problem was selected and how the context justified investment.

Problem Framing Map

Issue

A music API with collaboration, upload, cache, and export behavior needs clear boundaries so heavier background work does not degrade request latency.

Context

The project was framed as a system-design exercise inside the IDCamp backend track, with explicit attention to queue-based export processing and modular backend responsibilities.

Why Selected

It is a strong backend portfolio case because it proves architecture judgment through service boundaries and asynchronous flow design rather than feature count alone.

Problem statement

A music API with catalog, collaboration, upload, and export behavior needs clear boundaries so latency-sensitive requests are not coupled to heavier background work.

Solution thesis

Structured the project around a main backend service and a queue consumer, keeping asynchronous export processing separate from the request-response API path.

Research and Evidence

What supports the narrative

Evidence is surfaced with its source type and credibility note so the recruiter can quickly see what is directly backed versus intentionally constrained.

Architecture scope

local

The source structure explicitly separates API handling from queue-consumer background work.

Credibility: Backed by the project summary, architecture description, metrics, and README-backed sources.

Cross-cutting concern coverage

local

Auth, cache, collaboration, upload, and export concerns are all represented in the implementation narrative.

Credibility: Supported by the responsibilities, stack decisions, and documented project evidence references.

Credibility Notes

●The case is positioned as backend system-design and modularity evidence, not as a measured production-scale service.
●No latency benchmark, throughput claim, or live deployment outcome is implied beyond the source-backed architecture story.

Who The User Was

User framing stays explicit

When formal research artefacts are not available, the page still explains who the work served and why that user framing is justified by the existing sources.

Primary user

Backend maintainers who need a music-service architecture with safer background export workflows.

Its strongest proof is the explicit separation between API handling, worker execution, and cross-cutting modules.

System consumer

Authenticated clients interacting with catalog, collaboration, upload, and export-facing backend capabilities.

The problem framing and implementation narrative explicitly mention these consumer-facing backend responsibilities.

Decision Flow

How design thinking translated into decisions

The goal is to show the trace from research and insight to concrete product or system decisions, then to the outcomes those decisions supported.

Design Thinking Flow

Each step keeps the movement from evidence to action explicit before the rationale expands it.

Step 1
Boundary framing
Defined the problem around latency-sensitive requests versus heavier background tasks before optimizing implementation detail.
Signal: Export processing was isolated from the core request-response path.
Step 2
Responsibility mapping
Organized auth, cache, collaboration, upload, and export concerns into clearer backend boundaries.
Signal: The source structure reflects distinct service concerns rather than one overloaded handler layer.
Step 3
Scalability reasoning
Used queue and worker separation to show safer long-running task handling.
Signal: RabbitMQ-backed background flow became part of the portfolio narrative.

Decision Rationale

Each decision keeps the path from insight to execution visible before ending on the outcome signal.

Queue-based export

Insight

Long-running export work can distort API responsiveness when forced into synchronous endpoints.

Decision

Used a queue consumer to process export jobs outside the main API request path.

Outcome

The project demonstrates asynchronous backend thinking that stays reviewer-visible.

Separate cache and job layers

Insight

Caching and background jobs solve different operational problems and should not be blurred together.

Decision

Used Redis for cache-oriented concerns and RabbitMQ for queue-based background processing.

Outcome

The architecture reads as modular and easier to extend.

Solution and System Execution

Execution choices and delivery details

This section preserves the technical and operational substance: architecture, responsibilities, trade-offs, and implementation quality signals.

System Design

Hapi-based backend API paired with a queue consumer for background jobs, using PostgreSQL for persistent data, Redis for cache-oriented concerns, RabbitMQ for queueing, and JWT for access control.

Source-backed Impact

Demonstrates scalable backend thinking through modular service boundaries and safer handling of long-running export work.

Responsibilities

●Implemented backend service boundaries for music catalog workflows
●Separated export processing from latency-sensitive request handling
●Organized cross-cutting concerns across auth, cache, collaboration, and upload modules

Stack Decisions

●Used queue-based export processing instead of heavy synchronous request work
●Used Redis and RabbitMQ to separate cache and background job responsibilities
●Kept API and worker concerns in distinct project areas for clearer deployment reasoning

Trade-offs

●Accepted additional service coordination to avoid coupling heavy exports to API latency
●Prioritized modularity and reviewability over a minimal single-process implementation

Challenges

●Keeping cross-cutting backend modules understandable across API and worker paths
●Designing export behavior without adding unsupported deployment or performance claims

Outcomes and Proof

What was delivered and what can be verified

Outcome claims remain conservative and source-backed, while proof records and recruiter-safe links surface the strongest verification trail available.

Validation Signals

●Separate API service and queue consumer project areas are documented in the source-backed project record.
●README-backed evidence covers auth, cache, collaboration, upload, and export concerns in the implementation story.

Source-backed Outcomes

●Separate API service and queue consumer project areas
●Auth, cache, collaboration, upload, and export concerns represented in the source structure

Proof

IDCamp Backend Project
Backend API and queue consumer project completed
IDCamp 2024

Links

Repositoryrepo

Retrospective and Limits

What the project proves, and what it does not

Strong case studies show both what was learned and where the current evidence stops.

Retrospective

Next iteration should strengthen setup documentation, add request-flow diagrams, and define measurable quality checks before claiming production readiness.

Evidence Limits

●Current sources do not provide deployment topology, queue throughput metrics, or production monitoring evidence.
●Scalability language should remain architectural and qualitative unless stronger measured evidence is added later.

Lessons

●Queue-based export flow is safer than forcing heavy work into synchronous endpoints
●Service decomposition improves future observability and deployment reasoning