Seasonal peak load at public pools

A public pool isn't evenly loaded. From June to August it serves 4–6× the guests of the winter months. In May 2026 a heat wave produced 3,200 entries in a single Saturday at one of our pools, against an 800 baseline. This article is about how Lunda held up.

The load profile

2025 full-year data from a mid-size public pool:

• January–April — daily average 250–400 entries, weekend peaks to 600.
• May — transitional, 400–800 / day, weather-dependent.
• June–August — average 1200–1800 / day, peak Saturdays 2500–3500.
• September–December — drop back to 200–500 / day.

The peak-to-trough ratio is about 1:15. A system that comfortably serves 250 guests in January has to serve 15× as many in August with the same UX.

Saturday, 16 May 2026

A heat wave arrived on 16 May: 34°C Saturday. A rural public pool customer had 800 guests by 09:00, 2100 by noon, 3200 entries by 21:00. The May Saturday average is 800.

What the system did:

• POS response time stayed between 100–180 ms throughout (target: <200 ms). No UX degradation.
• Entry gates stayed sub-300 ms — the 6 gates served 8400+ entries over the day.
• 1 incident: a 3-minute backend slowdown at 16:42 (Postgres query queue filled). The capacity dashboard alerted, DevOps watched, it recovered on its own.
• The capacity dashboard flagged "95% capacity" once at 14:00 — reception manually enabled waitlist mode for 12 minutes, during which 47 guests joined the queue.

Net: 3200 entries, 0 guest complaints about the system (only about the heat).

The capacity dashboard

Every Lunda admin UI includes a live capacity dashboard. It shows:

• Current headcount — how many are inside right now.
• Entry / exit rate — over the last 15 minutes.
• Estimated occupancy — against the licensed maximum for the venue.
• Gate queues — estimated waiting count from turnstile sensors.
• Waitlist status — on/off, how many are on it.

The dashboard auto-refreshes every 5 seconds; reception and operations watch it continuously.

Waitlist mode

When the venue hits 95% occupancy, operations enables waitlist mode. From then on:

• New guests can't enter immediately — they go on a list (phone number or Lunda app account).
• When someone exits, the first waiter gets an SMS: "You may enter; arrive within 15 minutes."
• If they don't arrive in 15 minutes, the next waiter is called.

The waitlist is off by default. It only activates when operations enables it. On Saturday 16 May 2026 it was active for 12 minutes, 47 guests signed up, 41 came back in.

Infrastructure tuning

For peak load, Lunda tuned three areas:

1. BullMQ background jobs — non-critical work (invoice printing, NTAK submission, email) goes to BullMQ, off the critical path. At peak the queue can fill with 800 jobs and drains slowly in the evening.
2. Postgres connection pool — default 20 connections / node, raised to 60 for peak. Across 3 nodes that's 180 concurrent connections.
3. Read replica for reports — admin reports (till report, NTAK report, pass analytics) read from a replica, not the master. POS transactions still use master.

Lesson

The seasonal peak isn't unexpected, it's predictable — it comes every year and the maximum is different every year. Lunda is built to handle the 15× swing without friction. Saturday 16 May 2026 proved it: 3200 entries, 0 complaints, one 3-minute incident.