Case 01Operations platform with connected-device automation
Making booking and access work more dependable
- Property operations
- Role
- System design, backend engineering, integration work, dashboard work
- Contributed to
- Client-owned repositories. I was a major contributor.
- Stack
- TypeScript
- NestJS
- Fastify
- Prisma
- PostgreSQL
- BullMQ
- Redis
- JWT
- Scheduled jobs
Situation
A property operations team relied on separate services for reservations, temporary door access, guest messages, and internal tracking.
A single booking could trigger several external requests. If one provider responded slowly or failed, part of the process could stop while another part had already completed. Cancellations also needed careful handling because an access code left active on a physical lock creates a real security problem.
Staff needed a way to see the state of each booking without piecing it together from several services.
What I built
I designed a new backend around the full life of a booking. Incoming reservation events are validated and recorded before a background queue takes over the remaining work. Access setup and guest communication continue outside the original web request.
Each stage records its own status. Failed work can retry without repeating stages that already succeeded. The system schedules access removal for checkout and starts early removal when a booking is cancelled.
The administrative side exposes booking state, device information, access status, and failed work that needs attention.
What changed
- A booking can start the access workflow without waiting for every external provider to respond.
- Failed stages can be retried independently.
- Repeated events are handled safely and do not create duplicate access records.
- Staff can inspect the current state instead of guessing which service failed.
- Temporary access follows the booking from acceptance to checkout, including cancellation.
Engineering notes
The backend uses TypeScript with a modular server framework. A relational database holds the booking and property data, along with the device and access data.
A Redis-backed job queue manages work that may take time or fail temporarily. Idempotent handlers make repeated events safe. An audit trail records each stage.
Webhook signatures protect the public entry point. Authentication, request validation, rate limits, health checks, and structured logs support day-to-day operation.
The queue is justified because several external APIs must complete in the correct order and recover from temporary failure.
Try the model
A booking is recorded, then a queue runs access setup and the guest message on their own. Either one can retry without repeating the other, and access is removed at checkout or as soon as the booking is cancelled.
A simplified working model of the real system. No client data.