System / 003
Bookt
Salon booking platform
Role
Full-Stack & DevOps Engineering
Period
Sep 2024 – Jul 2025
Domains
2
Context
Power Match (Denmark)
Primary Outcome
Stabilized production system to zero planned downtime with a rebuilt real-time calendar engine.
Last updated 2026-08-11
01 / Context
Bookt is a free salon booking platform built for small Danish salons — a unified calendar, shareable booking links, automated appointment reminders, cash-register integration, and a mobile app, funded only by optional payment-terminal services.
02 / Problem
The production system was experiencing reliability issues and performance bottlenecks that directly impacted salon owners' daily operations. It needed stabilization, faster response times, and a robust real-time booking infrastructure — without breaking the "simple and free" promise to its users.
04 / Architecture
CLIENT | v NGINX | v API SERVICE ----> REDIS (CACHE) | v POSTGRESQL GITHUB ACTIONS ----> DOCKER ----> PRODUCTION
The booking API sits behind Nginx with Redis in front of PostgreSQL for the hot read paths — calendar views and availability checks — which were the primary source of the original latency problems.
05 / Engineering Decisions
Decision / 01
Booking confirmations and calendar reads were slow enough to affect daily salon operations.
Chosen: Redis caching layer in front of the calendar read paths, paired with query optimization on PostgreSQL.
Why: The read pattern (many calendar checks per booking) was heavily skewed toward reads, making caching the highest-leverage fix.
Trade-off: Added a cache-invalidation surface that has to stay correct whenever a booking changes.
Decision / 02
Deployments were manual and inconsistent, contributing to downtime.
Chosen: Containerized the application with Docker and moved to GitHub Actions CI/CD.
Why: Removes human error from the release path and makes every deploy repeatable.
Trade-off: Upfront time cost to write and test the pipeline before it paid off in reliability.
06 / Reliability / Failure Modes
Scenario
Two bookings attempt to claim the same calendar slot.
Expected
Only one booking is confirmed; the other sees the slot as taken.
Protection
Conflict detection rebuilt into the real-time calendar synchronization layer.
Recovery
Rejected booking attempt is surfaced immediately to the user with alternative slots.
08 / Technology
BACKEND
Node.js, PostgreSQL
DATA
Redis
INFRASTRUCTURE
Docker, GitHub Actions, Nginx, Linux
07 / Contribution
My Contribution
- —Stabilized the production backend by identifying and resolving reliability bottlenecks causing downtime
- —Optimized database queries and implemented Redis caching to improve API response times
- —Rebuilt booking workflows with real-time calendar synchronization and conflict detection
- —Implemented an automated appointment reminder system to reduce no-shows
- —Containerized the application with Docker and established CI/CD pipelines
- —Set up monitoring and alerting to catch issues before they reached end users
09 / Outcome
- —Zero planned downtime after stabilization
- —Significantly faster booking confirmations via Redis caching
- —Automated reminder system that measurably reduced no-shows
10 / Lessons
- Most of the "reliability" problem turned out to be a caching and query problem, not an infrastructure problem — profiling before rearchitecting saved a lot of wasted effort.
- A repeatable CI/CD pipeline is a reliability feature, not just a convenience — most of the original downtime traced back to manual deploy steps.