Build a Booking System You Can Explain in a Backend Interview

A useful portfolio project gives you decisions to discuss. A booking system is a strong example because it connects data modeling, concurrency, payment state, time handling, and user experience in one manageable domain.

Build a mentorship-booking service rather than another generic CRUD app. Keep the first version small: a user chooses a fixed-duration slot, starts checkout, and sees a confirmed booking with a join link after payment verification.

Describe the invariants first

Write the rules that must stay true:

• A host cannot have overlapping confirmed sessions.
• A user can only read or cancel their own booking.
• A payment callback cannot confirm a booking twice.
• The server decides the price and verifies payment state.
• Expired pending holds do not block availability forever.

These rules are more valuable than an early list of frameworks. Each should lead to a design choice and a test.

Separate bookings from payments

A booking and a payment do not have identical lifecycles. A customer can abandon checkout, retry payment, request cancellation, or receive a refund after confirmation.

Use an explicit state model rather than one isPaid flag. For example, a booking might be pending, confirmed, cancelled, or completed. A payment can separately be pending, paid, failed, or refunded. Record provider order IDs and payment IDs with appropriate uniqueness constraints.

Never treat a browser redirect to a success page as sufficient proof of payment. The verification details depend on your payment provider; follow its official integration contract when implementing a real gateway.

Design the overlap rule

For half-open intervals, an existing session overlaps a proposed one when:

existingStart < proposedEnd
AND existingEnd > proposedStart

A session ending at 11:00 does not overlap one starting exactly at 11:00. If you need a preparation buffer, express it as a separate scheduling rule.

Two requests can both check availability before either inserts a booking. Explain how you prevent this race. Options depend on your database and model: reserving predefined slots with a unique key, locking the relevant host or slot during a transaction, or using database-supported interval constraints.

Do not claim that checking availability in application code alone prevents double booking.

Keep time unambiguous

Store actual session instants consistently and preserve the intended timezone for display. The booking screen should label its timezone explicitly. Reject past slots on the server even when the date picker also disables them.

Test boundary cases: a session starting right now, adjacent sessions, a cancellation close to the deadline, and users viewing the same instant in different zones. A date string without a timezone is not a complete scheduling contract.

Make retries safe

A payment webhook may be delivered again. Store an event identifier or make the transition itself idempotent. Update payment and booking state within the required transaction boundary, and make notification delivery retryable without creating duplicate business records.

A useful failure to demonstrate is a process crash after payment confirmation but before email delivery. The customer should still see the confirmed booking in their dashboard. Email should be a notification, not the only place the join link exists.

Present evidence in your README

Include a small state diagram, the booking API contract, ownership rules, concurrency tests, and a short failure-recovery walkthrough. Use clearly marked test gateway data; do not put real payment credentials in the repository.

In an interview, walk through one normal request and one failure case. Explain why your first version uses fixed slots, which assumption would break with variable durations, and how you would evolve the design. A project with explicit limits is easier to trust than one claiming to solve every scheduling problem.

Practise discussing the design through interview preparation or book a mock interview for feedback on your explanation.