Event Management System

McIntire employs a wide range of third-party tools to handle different aspects of event management. We built a system to merge all of the disconnected parts and pieces into one standardized content stream.

The Challenge

Event management can be a nightmare -- particularly when you have multiple systems doing fractional things related to events. Room reservations, invites, notifications and marketing, calendaring, registration, etc. McIntire had all of these things and they were feeling the pain of this fragmented landscape. Plenty of commercial products exist to address the problem, but none of them could quite deliver on what was really needed: a system that could streamline the event management process across applications and provide a simple mechanism for communicating those events to the right people.

Never ones to settle for just “meh”, we decided to create a bespoke system that could leverage the tools already in use at McIntire. We got to work and immediately discovered why there was no silver bullet solution on the market: it’s a really hard problem to solve. It was quite a journey, but what we ultimately put into production is an elegant, distributed system that scales and flexes as needed.

System Design

Separation of concerns

Under the hood, the system has three main parts. First, the data-pulling microservices. These guys are solely responsible for fetching events from a respective external source, cleaning and standardizing the response, and then sending it to the second character in our story: a REST API built with MongoDB, NodeJS, and Express. This API layer is the sole provider of data to all of the frontend applications. And finally, there is a UI for managing all of the aggregated events before they are publicly visible on the world wide web. As with most distributed systems, there are a lot of moving parts, but even so, the entire system clocks in at about $20/month.

UI Elements

A little UI gloss

But alas, a standardized, well-structured JSON response is only part of the equation. To accommodate us humans, we created a dedicated frontend application to display the data; it’s filterable, clean, on-brand, and suitable for both the casual peruser and those who are ready to take action (register). Additionally, we wired up all of the other web properties with event feed components. Now, when a new event is published, it’s automatically distributed everywhere it needs to go and with an aesthetic to match.

System Feature

Intentionally fluid

Change is the only constant, as they say. At the outset, we knew that there was a high potential for new or changing data sources, so we took great care to ensure our system could flex as needed with minimal disruption to the core functionality. Two design decisions have proven clutch in that regard: MongoDB and the microservice model.