Cloud Infrastructure for Venue Booking: Zero Crashes in 6 Months
How SociiLabs moved ZapBook off a single VPS that crashed weekly and onto auto-scaling Google Cloud Run, with zero crashes in the first six months and zero-downtime deploys.
Client · ZapBook · app.zapbook.ai
About the project
01 Project overview
Engagement
12 months, Phase II ongoing
Delivery team
Embedded team of 4
Core technologies
Google Cloud Platform, Cloud Run, Docker, Square API
ZapBook is the booking platform behind curling clubs, bowling centres and activity venues, with five years of continuous growth behind it.
SociiLabs joined at discovery as an embedded team of 4. That growth had outgrown a single VPS that crashed weekly, so we moved all production traffic onto Google Cloud Run. The embeddable booking widget followed, and reached 15+ venue sites in its first 90 days.
In the six months after cutover, ZapBook recorded zero crashes, and in-venue Square payments now reconcile to bookings automatically.
02 The challenge
Give five years of growth an architecture built for the next five, without a minute of downtime for the venues running on it.
01
Venue traffic arrives all at once.
Leagues open registration on the same evening. Weekend slots sell out on Friday afternoon. Booking platforms get their heaviest load in short, sharp peaks, and infrastructure sized for an average day isn't enough.
02
Venues can't close for a migration.
Operators take bookings seven days a week, often at the counter. The move to new infrastructure had to happen live, with every booking, gift card and payment carried across intact.
03
Operators reconcile every dollar.
Venue owners compare booking reports against their bank and their point-of-sale system. Every one of 12+ reporting verticals, from revenue to inventory to staff, had to match the source data exactly.
04
Growth now comes from distribution.
ZapBook's next customers would come through venue websites and in-person payments. That meant a booking widget any venue could embed, and Square payments that settle back to the right booking.
Why SociiLabs
One team for the cloud, the code and the numbers.
ZapBook needed a partner who could change the foundations without disturbing the venues standing on them. Moving to the cloud was only part of the work. Our scope also covered containerisation, the deployment pipeline, a full reporting rebuild, the booking widget and Square reconciliation. As an embedded team of 4, we ran the old and new stacks side by side, compared their outputs before cutover, and shipped every change through protected branches, automated tests and rolling deploys.
What we built
03 Solution
The cloud platform, and the reporting and payments system on top of it. Auto-scaling services absorb venue peaks, every release ships with zero downtime, and the numbers reconcile to the cent.
Auto-Scaling Cloud Run
Every service runs in a Docker container on Google Cloud Run and scales with demand, replacing the single VPS the platform had outgrown. League-night and Friday peaks are absorbed automatically.
Zero-Downtime Pipeline
Each merge is built, tested and rolled out gradually, with automatic rollback on failed health checks. Deploys ship with zero downtime, so a release never interrupts a venue mid-booking.
12+ Verified Reporting Verticals
Revenue, bookings, inventory, gift cards, staff and more were rebuilt and checked against source data before release.
White-Label Booking Widget
One embed snippet puts ZapBook booking on any venue website in the venue's own branding. It went live on 15+ venue sites in its first 90 days.
Square Payments + Reconciliation
In-venue Square payments attach to the right booking automatically and settle back into ZapBook reports, so counter sales and online bookings appear in the same numbers.
Live Migration
Old and new stacks ran in parallel before cutover, so their outputs could be compared before any venue depended on the new one. Every booking, gift card and customer record was carried across intact.
Architecture
System diagram
INSIDE A LIVE MULTI-VENUE BOOKING PLATFORM
Scale up for the peak. Roll back before anyone notices.
Cloud Run adds capacity as demand rises and releases it when the evening ends. Every release rolls out gradually behind health checks, and a failed check returns traffic to the previous version automatically. Database migrations run backward-compatible, so an old and a new version can serve traffic side by side. Square webhooks are verified and processed idempotently, so a retried event never posts a payment twice. Load tests and release candidates run in a staging project that mirrors production, never against live venue data.
Delivery timeline
Off a single VPS and onto Cloud Run. Then zero crashes in six months.
Our embedded team of 4 began with discovery and architecture. Production traffic then moved from a single VPS to Cloud Run, and the white-label booking widget and Square reconciliation followed on the new platform. It was a 12-month engagement, and Phase II is ongoing.
WEEK 1
Discovery & Architecture
Map services, data and peak-load patterns.
CUTOVER
Cloud Run Cutover
All production traffic moves off the single VPS.
WIDGET LAUNCH
Booking Widget Live
White-label embed ships; 15+ sites in 90 days.
SQUARE LAUNCH
Square Reconciliation
In-venue payments settle to bookings.
CUTOVER + 6 MO
Zero Crashes
Six months crash-free. Phase II is ongoing.
HOW IT STAYED RELIABLE
Every release can roll itself back.
DEPLOYMENT SAFETY
Releases roll out gradually.
New versions take a small share of traffic first. Health checks decide whether a rollout continues. A failed check rolls traffic back to the last good version without anyone being paged.
DATA CORRECTNESS
Reports match the source.
Each of the 12+ reporting verticals was verified against source records before release. Square payments reconcile to bookings automatically, and any mismatch is flagged for review.
OBSERVABILITY
Problems surface before venues see them.
Uptime checks, error-rate alerts and latency dashboards cover every service. On-call engineers see a problem forming well before a venue operator would.
AUTOMATED TESTS GATING EVERY RELEASE
Every merge
DOWNTIME PER PRODUCTION DEPLOY
0
WHERE LOAD TESTS AND RELEASE CANDIDATES RUN
Staging
04 Impact & results
Impact & Results
Peaks absorbed. Releases made routine. Revenue reconciled.
- Zero crashes in the first six months after cutover, down from weekly crashes on the single VPS it replaced.
- Capacity that follows demand, with Cloud Run adding containers as league-night and weekend traffic rises and releasing them when the evening ends.
- Room to grow on the same platform, because new venues, widget embeds and in-venue payments now add load to services that scale, instead of to a single server.
- Zero-downtime production deploys, rolled out gradually with automatic rollback on failed health checks. The crash figure covers the first six months after cutover; we'll update this page as Phase II ships.
- 12+ reporting verticals rebuilt and verified against source data, so venue operators can reconcile ZapBook reports straight to their bank.
- 15+ booking widget deployments in 90 days, and in-venue Square payments reconciling to bookings automatically.
Crashes in the first six months after cutover
0
Booking widget deployments in the first 90 days
15+
Reporting verticals rebuilt and verified against source data
12+
Your product roadmap is waiting on engineering. We ship it.
SociiLabs has shipped 10 projects in 2025–2026 and is rated 5.0 on Clutch. Senior engineers, fixed-scope sprints, and your repo, your cloud, your IP from the first commit.
Book a discovery call