AWS and FileMaker Success Story: Chicago Public Schools Solution

Introduction
Chicago Public Schools needed the ability to publicly post results of which students were accepted to various enrollment programs through the Chicago School System. There needed to be an interactive capability for students and their families to accept and reject various programs, as well as manage their waitlist selections in the event that openings became available in other programs, based on other students' choices.

In order to ensure fairness, the application needed to be made simultaneously available to all 60,000 students and their families, all of whom were highly motivated to access it as soon as possible to review their offers and make their selections. This creates a highly concentrated load within minutes of making the site available to the public.

Successful Solution
In past years, the information was published and mailed to parents or available as PDF online. This method not only was more cumbersome but was more time consuming to generate and distribute results. 360Works, in conjunction with Thorsen Consulting, re-wrote this process with an AngularJS client-side application, hosted on S3 with CloudFront caching, and utilizing DynamoDB as the database, with auto-scaling enabled. In addition, 360Works used a sync tool developed by them called MirrorSync in order to replicate the DynamoDB data to Claris FileMaker, a traditional database tool used for reports, administration, and data entry.

Because of the problems they had experienced in previous years, Chicago Public Schools arranged for a formal load testing process, using an outside vendor capable of simulating 40,000 simultaneous connected users. That vendor reported that ?The application performance with 40,000 simultaneous users was identical to a single active user.? 360Works is proud of this customer feedback, and takes it as a testament to both our data modeling skills and DynamoDB scalability.

AWS Services Leveraged:

• API Gateway is used as a front-end for the Lambda login service. We utilized the stages feature of the API gateway to create a staging and production environment, with environment variables set in the API gateway separately for each stage to control what the test and production users would see on the site.
• CloudFront was used as a caching layer for all static pages hosted on S3. Since most of the users are in Chicago but the AWS region was in Ohio, this made page load speeds faster for those users, by using the Chicago edge location.
• DynamoDB was really the heart of the system; it synced with an internal relational database that contained all the student and application records. Requests were made directly from the client browser, using the JavaScript SDK to DynamoDB. By utilizing unguessable UUIDs as primary keys, and creating an IAM Policy that prevented the ability to scan for records, we were able to achieve a secure environment without the overhead and added complexity of an API Gateway / Lambda function between the user and DynamoDB.
• Lambda?s main function was to handle the login process. Since we wanted users to be able to talk to DynamoDB directly, without any middleware, we needed to provide them with UUIDs of records that they were allowed to view. A custom Lambda function took their login credentials and returned the relevant UUIDs that they were allowed to view and edit.
• EC2 for Windows: the relational database that syncs with DynamoDB was hosted using EC2 for Windows. We used Claris FileMaker for this, which is not supported by RDS, so we hosted this on an instance that we managed.