EVENT PLATFORM
The integration layer that made 80+ services feel like one product.
This is a B2B webinar and event management platform. Its complexity isn't in the UI, it's in the backend surface it exposes: 80+ third-party integrations, 6 entity types with intricate relationships, and 8 independently maintained product modules.
Three things that don't scale without architecture.
Integration sprawl
Each of the 80+ connected services had different OAuth flows, token refresh strategies, error shapes, and data contracts. Without abstraction, every integration would need its own bespoke handling, compounding maintenance debt exponentially.
Module complexity
Six entity types (Events, Contacts, Lists, Broadcasts, Funnels, and Forms), each with their own CRUD flows, relational views, and cross-entity references. A change in one module had implicit effects on others. Isolation was a prerequisite for velocity.
Scale without instability
A product that handles event registration, email broadcasts, and payment flows simultaneously needs state management that doesn't crack under concurrent operations. Stale state or race conditions in a live-event context aren't just bugs, they're revenue loss.
Three principles that held it together.
Unified integration layer
A single abstraction wrapped all 80+ OAuth flows: one interface for token exchange, refresh, and error normalization. Adding a new integration meant implementing a known contract, not inventing a new pattern.
Every service connector implemented the same interface. Token refresh, error codes, and payload shapes were normalized at the adapter layer, so no integration-specific logic ever reached the UI. Rate-limit handling and retry logic lived in the shared adapter, not per-service.
Entity-driven architecture
Six core entity types were modelled once and consumed consistently across every module. A change to how a Contact behaved propagated once, not six times.
Zustand stores per entity type; selectors kept derived state co-located with source. React Query handled server sync with per-entity query key namespacing, with no cross-contamination between modules. Shared hooks enforced consistent mutation patterns across all 8 modules.
Incremental module ownership
Each of the 8+ product modules was self-contained: its own layout, routing context, and data boundary. Features were developed, tested, and shipped in isolation without touching adjacent modules.
Feature flags and module-level code splitting kept the bundle clean. Dynamic imports per module; new modules added without modifying existing entry points. The architecture enforced isolation automatically: no discipline required at the call site.
Integration Hub
One dashboard to connect, manage, and monitor all 80+ third-party services. OAuth flows are standardized: connect a new tool in one click, revoke in one more. Status, sync history, and error states visible without digging.
Multi-module Event Management
Eight independently maintained product modules (Events, Registrations, Broadcasts, Funnels, Forms, Contacts, Lists, and Reporting), each self-contained, each shipping without touching the others.
Entity Relationship Management
Six core entity types (Contacts, Events, Lists, Broadcasts, Funnels, Forms), each with full CRUD, relational views, and cross-entity references. All modelled once, consumed consistently across every module.
