Architecting the Circuit App

Learn about this year’s CIRCUIT conference's innovative mobile app.

This year’s CIRCUIT AEM Developers conference was coupled with a mobile application which, along with providing the end user with information concerning sessions and speakers, would track the user’s movement around various regions related to the conference in order to award them with precious achievements. While the Cordova application’s construction using AEM Apps was the focus of my presentation with Pat McLoughlin, the suite of AWS technologies which went into servicing the application constituted an equally substantial if not greater part of the overall architecture.

Application Architecture

Similar to the Mobile Application itself we looked to achieve a number of goals in architecting the Web Services and System Components supporting the application.

  • Simplicity – every element of the system should have a well defined responsibility
  • Modularity – system elements should be easy to insert and remove to and from the broader system architecture
  • Scalability – as traffic to the services and supporting components peaks during the conference proper the system should scale to meet the needs of the users

Each of our technology and design choices aimed to service one or more of these goals.

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.

By utilizing Lambdas we were able to break up and isolate the various system operations, giving us the ability to easily modify system components without having to worry about breaking other aspects of the system. Scalability was also achieved by the very nature of Lambdas. New instances of Lambdas could be created and destroyed based on need so as throughput increases so can the number of parallel instances of individual Lambdas. Also of note was the temporal inexpensiveness of Lambdas from a development perspective, giving us the ability to quickly slot in new elements of functionality in the form of new Lambdas reacting to the existing SNS Topics, again without impact to the already deployed elements of the application.

For more on CIRCUIT, mobile application development, AEM or AWS, you can check out presentations on SlideShare, shout out to Paul Michelotti or Pat McLoughlin.