API servicemedium

Meeting room booking API

A booking backend where double bookings are impossible: overlap detection, availability, time zones and concurrency.

Suggested effort
~4h focused work
Window
24 hours
Starts from
An empty repo
Stack
Your choice
Sign in to start this build →

Opens in a new tab. The clock starts when you press Start inside the environment, not before, and your workspace is kept while you step away.

Time window 24 hours. Suggested effort about 4 hours.

Context

An office with a handful of meeting rooms needs a backend for booking them. Double bookings are the number one complaint, so correctness around time ranges matters more than features.

Core requirements

  • Rooms: list rooms (seed at least 3 with name and capacity on startup).
  • POST /bookings with room, organiser email, title, start and end (ISO 8601 with offset).
  • Reject overlapping bookings for the same room with a 409 that names the conflicting booking. Back-to-back bookings (one ends at 10:00, the next starts at 10:00) are allowed.
  • GET /rooms/:id/availability?date=YYYY-MM-DD returns the free slots for that day between 08:00 and 18:00 office time.
  • DELETE /bookings/:id cancels a booking; only the organiser may cancel (pass their email in a header).
  • Persistence in SQLite or Postgres.

Acceptance criteria

  • Times are stored in UTC and the API accepts any offset; the office time zone is configurable (default Europe/London).
  • A booking lasts at least 15 minutes and at most 4 hours, starts before it ends, and is not in the past.
  • Two concurrent creates for the same slot cannot both succeed (transaction, constraint or lock; say which in the README).
  • Overlap and availability logic has unit tests including edge cases (touching ranges, a daylight-saving change day).

Stretch goals (optional)

  • Recurring bookings (weekly, N occurrences) that are created all-or-nothing.
  • Search: "any room with capacity of at least N that is free between X and Y".
  • An OpenAPI document served by the app.

Constraints

  • Any stack. Suggested: FastAPI + SQLite, Express/Fastify + SQLite, or Go + SQLite.

Deliverables (every project)

  • Source code committed in this repository (the grader diffs against the first commit).
  • README.md that replaces the stub, with: how to install, run and test it (copy-pasteable commands); the decisions and trade-offs you made; what you would do next with more time; and a short note on how you used the AI agent (what you delegated, what you checked or rewrote).
  • Automated tests that run with a single command (npm test, pytest, go test ./... or cargo test).
  • No secrets in the repository. Anything configurable reads from environment variables with safe defaults.

Ground rules

  • The 24-hour clock is a window, not a workload. Stop at roughly the suggested effort, then write down what you would do next. A small, finished, tested core beats a large unfinished one.
  • Use the AI agent as much or as little as you like: every prompt is recorded and the report shows how it was used. You are judged on the result and on whether you understood and verified what the agent produced.
  • The work is yours. PraxisAI uses it only to produce your assessment report.
Meeting room booking API: a 24-hour take-home project | PraxisAI