WORXMT.FUJI

What counts as a clash follows how the space is used: visitors and coworking share the floor and never block each other, meeting rooms clash only when their hours overlap, and a day hired out whole blocks everything. The calendar shows only free slots, but a slot can fill between opening the calendar and pressing send, so the server checks again before writing. Two requests arriving together would both pass that check, so after inserting, each reads the day again and backs out if an earlier booking now overlaps it. Earlier means created first, with the ID breaking a tie, so both sides rank the pair the same way and never both back out. The one that loses is removed before any email is sent.

When staff enter or move a booking that overlaps another, they are warned and can save knowing it is there. After saving, the server checks again, since a web booking or a second member of staff may have taken the slot between the check and the save. Confirming and cancelling only apply to a booking still in the state they expect, so a customer cancelling at the same moment is not overwritten by a confirmation — the staff member is told it has already changed. A customer's cancellation works the same way, and emails go out only when a row actually changed, so a double click does not send two. A cancelled booking cannot be reinstated, because its slot may have gone to someone else; it is entered again instead.

The link in a confirmation email is the booking's ID with an HMAC signature, so only its recipient can open or cancel it, and nothing is stored to make that work. The cancellation deadline, 17:00 the day before, is computed in Japan time whatever clock the server runs on, across the end of a month or a year. The customer page signs in by email: a 15-minute link, then a 30-day httpOnly cookie, and the two are signed for different purposes so one cannot stand in for the other. The sign-in form gives the same answer whether or not an address has bookings, and sends the email after responding, so not even the response time gives it away.

The dashboard sits behind Cloudflare Access, which sends a one-time code to approved addresses. The app does not take that on trust: every admin action verifies the token Access signs — issuer, audience, algorithm and an email on the allow-list — so a policy left misconfigured, or a request sent straight to the workers.dev address, still gets no booking data. With the settings missing it refuses rather than opens. In the database, row-level security is on with no policies and the public roles hold no grants, so names, emails and phone numbers are reachable only from server code with the service key, in modules marked server-only.

It runs on Cloudflare Workers' free plan, which allows 10 ms of CPU per request. With no incremental cache configured, even the pages generated at build time were being rendered again on every request, and past that limit the site answered with Error 1102. Built pages are now served from the static-asset cache without passing through Next.js at all. What depends on the visitor — the customer page, a booking's page, the admin — is read in the browser and fetched through server actions, so the page itself stays static.