Every booking product is the same product underneath. A padel club, a dental practice, a co-working space, a boat rental, a photo studio: different words on the interface, the same eight problems under it. What is free right now. Who gets the slot when two people ask at the same instant. What happens to a slot when the clocks change. Which cancellation rule applies to a booking made before the rule changed. Whether the request you retried after a timeout created one booking or two.
None of these problems is hard on its own. Together, and under real traffic, they are the reason booking systems get rewritten. The first version treats availability as a query and bookings as rows. The second version adds a lock. The third one discovers daylight saving time in production, usually in March, usually on a Sunday. The fourth one moves the cancellation policy out of the booking table and then cannot explain to a customer why their refund is different from what they were shown.
So we built the layer once, in the open, and today the repository is public: github.com/bookrail-dev/bookrail, Apache 2.0.
What Bookrail is, and what it is not
Bookrail is booking infrastructure for developers. It is the layer under a booking product, not the product. You build the interface, the pricing and the brand. Bookrail answers what is free, takes the capacity without ever giving it twice, freezes the rules that applied at the moment of the booking, and emits a signed event for everything that happens.
