slotline
A resource booking platform (rooms, courts, equipment) on Spring Boot. The core guarantees a single slot can never be double-booked - even under heavy concurrency.
A resource booking platform (rooms, courts, equipment) on Spring Boot. It looks trivial until two people click the same slot in the same millisecond. The core guarantees a slot is never double-booked, even under heavy concurrency.
Overview
Booking a slot looks like a row insert, and many developers write it exactly that way. The trouble is that the real difficulty does not live in the typical case but in the one millisecond where two people reach for the same free slot. slotline is built around that one millisecond, not around the booking form.
Everything else in the platform, the resources, the calendar and the views, wraps around a single guarantee: that a slot has exactly one winner. That is what decides whether the system is serious or only looks like it works until the first crowd.
The whole difficulty lives in one millisecond
A naive implementation does two steps: it checks whether the slot is free, then writes it. Between those steps there is a gap where a second user manages to see the same slot as free. Both pass the check, both write, and you have two bookings for one slot that nobody knew were possible.
slotline treats that as the main problem to solve, not an edge case. The domain model is clear precisely so this one guarantee is obvious when you read the code, not buried somewhere in a service layer.
Checking availability and writing the booking are not two separate operations. If they are, you have a race. The guarantee comes from the database, through a unique constraint on resource plus time slot, not from a check in application code.
The unique constraint moves the decision to the one place where concurrency is truly serialized: the database engine. It does not matter how many users click at once, because the winner is decided by an atomic write, and the losers get a clean conflict error instead of a silent double booking.
A test that can actually fail
It is easy to write a test that books once and checks it worked. That proves nothing, because it never touches the condition meant to hold. The valuable test fires many threads at the same slot at once and asserts that exactly one wins while the rest get a clean conflict error.
Simultaneous rush on one slot (illustrative)
The check is counterfactual: remove the unique constraint and the same test starts letting two bookings through. If the test stays green after the safeguard is gone, it was guarding nothing.
One winner, always
The result is a platform that behaves under load exactly as it does with a single user: a slot has one owner, full stop. There is no state where two people walk away with the same slot, because that possibility was cut out at the source, in the database, not patched over in the interface.
More projects
More work from the same category - see how we tackle similar challenges.
Have a similar project?
Get in touch - a quote is free and comes back within an hour.