EventsMo – Platform Overview

EventsMo is a cloud-native event management and attendee engagement platform. It gives event organizers a dashboard to run their events end-to-end, and gives attendees real-time interactive tools during live sessions – plus supports co-branded/white-labeled experiences so enterprise clients can offer the platform under their own brand.

Traditional event tools are either static (a website with an agenda) or fragmented (separate tools for chat, networking, email, and branding). EventsMo consolidates event operations, live attendee interaction, identity, networking, and outreach into one platform – with the elasticity to handle sharp traffic spikes around live event dates without over-provisioning infrastructure year-round.

Core Capabilities

Organizer Dashboard & Core Platform API – Amazon EKS

The dashboard and the core event API run as separate containerized workloads on independent node groups (dashboard-api, scaling 1–2 nodes; eventsmo-api-prod, scaling 1–6 nodes). Because they scale independently, a surge in live-event API traffic never starves the organizer-facing dashboard of resources, and vice versa – each workload is right-sized for its own load pattern rather than sharing one undifferentiated pool of compute.

Real-Time Attendee Engagement – API Gateway (WebSocket) + Lambda

Live chat, notifications, and session interaction run through a WebSocket API (eventsmo-websocket) that manages connection state (onConnect, onDisconnect, onJoin, onLeave), paired with a second API (websocket-message) and an onMessage function that pushes messages out to connected clients. Because this layer is serverless, it scales to however many attendees are concurrently connected during a session and costs nothing to keep “available” in between events – the real-time experience is functionally always-on without being always-running.

Multi-Tenant Identity & White Labeling – Keycloak + Dedicated Lambda

Authentication runs as its own isolated workload (keycloak-small-t3a node group), separating identity from application logic entirely. A dedicated Lambda function serves branded responses through the same shared API Gateway used for real-time messaging. Together, these mean each enterprise client gets its own isolated login and its own branded front-end without EventsMo standing up separate infrastructure per client. This is the specific mechanism that lets the platform be resold under different brands.

Attendee Relationship Intelligence – ArangoDB alongside Amazon RDS

Core transactional data (accounts, events, sessions) lives in RDS PostgreSQL, while attendee-to-attendee and attendee-to-session relationships are modeled separately in ArangoDB on ec2 , a graph database. Splitting these means networking and recommendation features query relationship data on a structure built for traversal, rather than forcing that logic onto a relational schema not designed for it.

Growth & Retention, Architecturally Isolated – WordPress + Sendy

The public marketing site (WordPress, fixed 2-node EKS group) and bulk email delivery (Sendy, standalone EC2) each run on their own dedicated capacity, entirely separate from the live-event platform. A traffic spike from a marketing campaign or a large email send has no path to competing for resources with the actual event experience – acquisition infrastructure and product infrastructure are physically decoupled.

Uptime for the Moment That’s Public – Network Load Balancer + Dedicated Cache

A single NLB spans all 3 Availability Zones and routes into the EKS ingress through two target groups, while media is served through a dedicated cache instance with a static Elastic IP. This layer exists specifically for the narrow window where EventsMo’s failure would be most visible – mid-event, in front of a live audience – rather than for average day-to-day load.

Infrastructure home: eu-central-1 (Frankfurt)

previously ap-south-1 (Mumbai), same architecture, relocated for EU proximity/data residency.