Architecting the Circuit App

Region Event Tracking

Prior to considering the system itself we must consider what duties the system was responsible for performing. One of the principal pieces of information we were culling from the application users was their interaction with various regions set up around the conference venue, the after party, and the surrounding city. These regions were established using Geofences for coarse grained locations like the venue itself or the Gino’s East down the street or using iBeacons for fine grained locations like the coffee station and the WrestleMania arcade game. Region ìeventsî would occur when a user entered or exited a region and, in the case of iBeacon regions, when the user was near (within ~.5m to the extent the device can estimate such things) the beacon defining the region.

As these events occurred our system was responsible for persisting and analyzing the events. The analysis mechanisms would inspect both the latest and prior events to make assertions such as the current location of the user associated with the event or whether the user should be awarded an achievement based on the event having taken place. All of this needed to occur in near real time for the results of the analysis to be relevant to the end user.

Elastic Beanstalk Service Layer

Our service layer was written using Express.js and hosted from Elastic Beanstalk, AWS’s PaaS offering. The vast majority of the endpoints were essentially passthroughs to persistence in DynamoDB or to event notification via SNS (or both). By making sure the services themselves were stateless we could easily let Elastic Beanstalk scale up and down horizontally as traffic increased and decreased throughout the duration of the conference. With a scale of only hundreds of location events per minute it was not often that a single instance would not suffice, however this solution would easily scale up to much greater load volumes without any performance impact and without the need to add any complexity to the code itself.

Each time a location event occurred, the device would send a POST to the appropriate HTTP endpoint indicating the nature of the event. The endpoint in turn would store the event in DynamoDB and send a notification via SNS indicating the occurrence of the event.

SNS as the Glue

SNS was used as the event propagation mechanism across the various elements of the application. Once the web service layer received a POST from the client application indicating that a region event has occurred, it would persist the event to DynamoDB, publish the event to the appropriate SNS topic, and then wash its hands of it. Using an event mechanism such as SNS we were able to easily plug new modules/aspects into the broader system either as their development was completed or as we wanted to test out new functionality/gather new data. The choice of SNS ensured that we would be able to handle the peaks in throughput and configuration available, concerning the guarantee of event delivery made certain that we never missed data points.

We use SNS to propagate events to two different types of application elements, the Mobile Application itself and Lambdas. In the former case the message we were sending as the payload of the event was simply the string we intend to send to the user. In the later case we serialize JSON for the Lambdas to later consume and react to.

Lambdas for Event Processing

Once the web service layer published a region event to SNS, two Lambdas would consume the event, potentially in parallel. One, the ìUser Location Processingî Lambda, attempted to calculate the userís current location based on the event which just occurred. Another, the ìDevice Location Achievement Processingî Lambda, determined whether the user merited an achievement based on the nature of the event. This later Lambda, when it determined that an achievement is merited, (such as the “Early Bird Achievement” awarded to users entering the CIRCUIT conference venue Geofence prior to the start of registration on day one) it would persist the achievement record to DynamoDB and publish an achievement awarded event to an appropriate SNS Topic. The achievement award processing Lambda in turn consumed this event, determined whether a notification should have been sent to the individual user to whom the achievement was awarded or to all users based on the ìrarityî of the achievement. It would then publish a notification of the achievement to the appropriate SNS Topic or Application Endpoint.