Problem [Could Have Been] Solved

Problem statement

Earlier this year, one of our clients (I'll call them ACME Industries) approached us with the following problem: 

“We need 260,000 people to go online and select their size for a shirt. We need about 10,000 people to be able to select concurrently.”

After a short conversation with the client, the following requirements were identified.

Requirements

As conveyed by ACME and summarized by me:

1. User population
   • 260,000
   • Contacted 10,000 at a time
2. Sign-on
   • Single sign-on (SSO) from their intranet is required
   • SSO will send along personal and shipping information
   • Cannot sign on again after placing their order
3. Look and feel
   • ACME's client will provide a design specification
4. Application flow
   • Select a shirt size
   • Confirm their selection or return to (a)
   • Persist the order information to the database
5. Data export
   • Export the collected order information to some convenient format
6. Lifetime
   • The application needs to be live for an initial 2-3 week period. Any needs for the application beyond that are currently undefined.

View fullsize

Click to enlarge

Proposed technology stack

To address the stated requirements, we proposed the following technology stack:

• Server-side
  • Heroku
  • Node.js
  • Postgres
  • Express.js
  • AWS S3
• Client-side
  • Bootstrap
  • jQuery

where:

• Heroku is “infrastructure as a service.” It handles the tasks of deploying, building, managing and scaling your application, allowing you to focus on the functionality of your application. I have blogged more extensively about Heroku here.

• Node.js is an open-source, server-side execution environment for JavaScript. It has the largest repository of open-source utilities in the world.

• Postgres is a high-performance, open-source relational database. It competes with MySQL as the most popular open-source relational database. Of the two, Postgres is considered the more fully featured option.

• Express.js is a minimal application framework that sits on top of Node.js and helps automate the most common tasks.

• AWS S3 is short for “Amazon Simple Storage Service”. It provides simple, fast and efficient storage and is ideally suited for static assets like images.

• Bootstrap is a framework for building web-based user interfaces that automatically adapt to the screen size, whether the browser is running on a desktop, tablet or mobile device.

• jQuery is a library of JavaScript utilities that make it very easy to manipulate the contents of a web page. The library is cross-platform, available for all major browsers and operating systems, eliminating the often subtle and annoying differences between web browsers. jQuery is the most popular JavaScript library in use today, used on over 60% of all web sites in the world.

We proposed that any email communication to the users (e.g. an order confirmation) would come from outside this application. For example, an administrator might download all orders for a given day using the data export feature, then import the list into MailChimp in order to send an order confirmation.

View fullsize

Click to enlarge

Operational pricing

The beauty of Heroku is that it can scale your application on an as-needed basis. The downside to this convenience is that pricing becomes a bit nebulous. That said, the base prices are these:

• Postgres - $50/month (learn more)
• Application instances (a.k.a. “dynos”) - $25/month/instance (learn more)

So…

• If your application is getting modest volume and a single instance can keep up, then it will cost you $75/month total ($50 + $25 * 1).

• If your application needs two instances to keep up at all times, then it will cost you $100/month ($50 + $25 * 2).

• If your application normally needs two instances to keep up with usual traffic but you spike up to 10 instances for a single 12-hour period during the month, then it will cost you $103.23 for that month ($50 + $25 * 2 + $25 * 8 * 12 / 744 ), where 744 is the number of hours in a 31-day month.

Outcome

Sadly, this project never came to fruition. The original requirement for 260,000 total users, 10,000 of them concurrent, was scaled back significantly (15,000 total users, 500 of them concurrent) so that one of ACME's existing, lower-throughput solutions could be used.

Of course, the problem statement is generic enough that we expect to be able to use our proposed solution in the future. Time will tell!