Skip to main content

Counterfoil: From a Booking Monolith to an Event-Driven Platform

Ternary keeps Counterfoil's booking platform live and maintained while rebuilding it as Continuum — event-driven services with a reusable availability engine and a generated SDK for every surface.

Industry
Technology
Engagement
Platform build · Multi-quarter
Duration
14 months
Team
9 — eng, ML, design, ops
Year
2025–2026
A venue operations console: revenue and visitor totals, scheduled group visits with confirmed and pending states, a visitor enquiry inbox, and a point-of-sale cart offering cash, card and e-wallet payment.

How we approached the work, what we built, and why it matters.

The challenge

Counterfoil's first-generation product proved the model but grew into a monolith where booking, billing, and identity were tightly coupled — hard to evolve and hard to reuse across new surfaces.

Our approach

Ternary keeps the production platform stable and maintained while rebuilding it in parallel as Continuum: an event-driven architecture that separates concerns into independent services with clear API boundaries.

What we built

Continuum is organized as focused services — identity and tenancy, a booking engine, sales, and notifications — communicating through a reliable outbox-to-queue pattern, with a modern operator dashboard on top. The booking engine encodes a "Unified Booking Theory": a bitmask inventory model that computes real-time availability and fans updates out over WebSockets.

To make the platform reusable across products, every surface is served by a generated SDK — operator, customer, partner, and storefront — wire-generated from the API contract so web, mobile, and partner integrations stay in lockstep.

Where it stands

The original platform remains live and maintained; Continuum is in active development, moving the core booking logic into a foundation that multiple front-ends and partners can build on.

The work, up close.

The operator view: available balance and next scheduled payout beside a dated transaction history, and an analytics board comparing sales, check-ins and visitors across two selected periods.
The operator side — settlement and demand, on the same platform.

Related case studies.

All case studies

Have a similar problem worth solving?

Tell us where you’re headed. We’ll bring the engineering discipline to get you there.

Get in touch