A portfolio full of todo apps and weather dashboards tells a reviewer one thing: this person can follow a tutorial. That is not the signal you want when hiring has tightened and the people reading your repository are comparing you against candidates from everywhere.
The tightening is measurable. Between the second quarter of 2022 and the second quarter of 2025, the share of US tech job postings requiring 5 or more years of experience rose from 37% to 42%, while postings open to 2 to 4 years fell from 46% to 40%, according to Indeed Hiring Lab. Postings open to a year or less were just 18%. Experience is being asked for earlier, and a portfolio is the fastest way to show it before you have the job title.
The 5 projects below were chosen because each one contains a decision with no obvious right answer. That is the point. An interviewer cannot probe a CRUD API, but they can spend 20 minutes on how you kept a ledger balanced or how you stopped 2 buyers claiming the same listing.
What Makes These Different
Each project has a constraint that changes the design rather than adding to it.
The fintech project has to balance. The streaming project has to serve large files without your API process touching them. The course platform has to model access rules that change over time. The music project has to stay searchable as the catalogue grows. The marketplace has to handle 2 people acting on the same item within the same second.
None of those are solved by adding endpoints. They are solved by choosing a data model and a failure strategy, then living with the consequences, which is exactly what backend engineering is.
All 5 are language-agnostic. Build them in whichever language you want to be hired in, and if you have not settled on one yet, our comparison of backend programming languages covers the realistic options.
1. FinPay: A Fintech Payments Backend
Build a wallet and transfer service. Users hold balances, send money to each other, and see a statement.
The constraint is that the numbers have to add up under every failure. A transfer is 2 writes that must succeed together or not at all. Two concurrent transfers must never drive a balance below zero. A crash after the debit and before the credit cannot lose money. These force you into transactions, isolation levels, and an append-only ledger rather than a mutable balance column.
The realistic version of this problem is closer to home than most tutorials admit. Payment providers like Paystack and Flutterwave sit behind exactly this design, alongside Stripe, and every one of them reconciles against an immutable record rather than trusting a running total.
Design decisions to defend: ledger entries versus balance columns, idempotency keys on transfer requests, how you handle a webhook that arrives twice, and what happens when the provider times out but the payment succeeded.
2. A Movie Streaming API
Build the backend for a video service: a catalogue, user libraries, watch progress, and playback.
The constraint is file size. The instinct is to serve video through your API. Do that once and you learn why presigned URLs and byte-range requests exist, and why a content delivery network is not optional at this scale. Watch progress adds a second problem: a write every few seconds per viewer is a workload your primary database should not be absorbing directly.
Design decisions to defend: where transcoding happens and whether it blocks publication, how you authorise a playback URL without making it permanently shareable, and how you batch or debounce progress updates.
3. A Course Platform API
Build the backend for an online learning product: courses, lessons, enrolments, progress, and certificates.
The constraint is access control that changes over time. A user enrolled last month, their subscription lapsed, and they are halfway through lesson 9. What can they see? Now the instructor edits lesson 4 after 500 people completed it. Does their progress still mean anything?
These are versioning and entitlement questions, and they are the reason this project is harder than it looks. Most candidates model enrolment as a boolean and discover the problem when they try to write the statement.
Design decisions to defend: content versioning, how entitlements expire, whether progress is stored per lesson or as a completion set, and how you keep the course listing fast without recomputing progress on every request.
4. A Music Streaming API
Build a catalogue of tracks, albums, and artists, with playlists, listening history, and recommendations.
The constraint is search and relationships at scale. Artists have albums, albums have tracks, tracks appear on playlists, playlists belong to users, and everything needs to be searchable by several fields at once. A naive schema produces queries with 5 joins that get slower every week.
This is the project where indexing stops being theoretical. Understanding what an index actually costs on write, and when a denormalised read model earns its keep, is the lesson. Our guide to database indexing is a useful companion while you build it.
Design decisions to defend: your indexing strategy and what it costs on insert, whether recommendations are computed on read or precomputed, and how listening history is stored without unbounded growth.
5. An Online Marketplace API
Build listings, search, messaging between buyers and sellers, and a transaction flow.
The constraint is concurrency on a single item. Two buyers click "buy" on the last unit within the same second. One must win, cleanly, and the other must get a clear answer rather than a 500. That is a locking problem, and choosing between optimistic and pessimistic locking is a decision you will be asked to justify.
Add moderation, seller reputation, and a dispute state machine and you have a system with genuine complexity in its states rather than its size.
Design decisions to defend: your locking strategy and why, how search stays current as listings change, how messaging avoids becoming a second chat product, and what a disputed transaction does to the money.
How to Present Them
The build is half the work. The presentation decides whether anyone notices.
Deploy it. A live URL and a health check endpoint prove the project met configuration, secrets, and startup problems. Free tiers are sufficient, and several need no card.
Document the API properly. An OpenAPI page or a published collection, not a list of curl commands in a README.
Lead the README with the hard decision. First paragraph: the problem. Second: what you chose. Third: what it cost and what you would change. That structure is what turns a repository into an interview conversation.
Be honest about scope. "Single region, no horizontal scaling, tested to 200 concurrent users" is a stronger sentence than silence, because it shows you know where the limits are.
When you are ready to be asked about all of this out loud, the AI mock interviews are built for exactly that rehearsal.
Summary
An advanced backend project is not a bigger project. It is one where something can go genuinely wrong, and where your design is what stops it.
FinPay forces transactional correctness. The streaming API forces you to keep large files out of your request path. The course platform forces entitlement and versioning. The music API forces indexing and query design. The marketplace forces concurrency control.
Build one of them completely, deploy it, and write down the decision you are proudest of alongside the one you are least sure about. That second one is usually what gets you the offer, because it is the part that sounds like someone who has actually shipped.
Frequently Asked Questions
What Counts as an Advanced Backend Project?
A project is advanced when correctness is hard rather than when the feature list is long. Money that must balance, media that must stream, catalogues that must stay searchable under load, and marketplaces where 2 people can act on the same item at once all qualify. A larger CRUD application does not, however many endpoints it has.
How Many Projects Should a Portfolio Have?
Two or 3 built properly beat 10 started. Reviewers spend a few minutes per candidate, and depth is what survives that. One deployed system you can defend in detail is worth more than a repository list nobody opens.
Should I Build These With a Specific Language?
No. Every project here is language-agnostic, and the design problems are the same in Node.js, Python, Java, Go, or Rust. Build them in the language you want to be hired in. If you have not settled on one, our guide to backend programming languages compares the realistic options.
Do These Projects Need a Frontend?
Not for a backend role. A documented API, a Postman collection or an OpenAPI page, and a README that explains the design will be read more carefully than a user interface. Spend the time on clear API design and a deployed environment instead.
How Do I Make Sure the Project Gets Read?
Open the README with the hardest decision you made and how you resolved it. Reviewers skim code and read reasoning. A repository that leads with a setup guide looks like a tutorial, and one that leads with a trade-off looks like engineering.
Are These Realistic Without a Paid Cloud Account?
Yes. Every project here runs on free tiers or self-hosted tooling. Use an S3-compatible store with a free allowance rather than a paid bucket, a managed database free tier for storage, and a container host with a free plan. Say so in the README; working within a constraint is a point in your favour, not against it.
