Prerequisites

Before attempting this assignment, please watch at least Lectures 1--11 (and do the accompanying readings).  Later lectures are also helpful for this assignment, but the first nine lectures are absolutely essential.

Learning Goals

Students will practice and demonstrate the design of scalable software architectures by:

• Breaking a complex system into a set of functionally independent, but interacting, components.
• Designing a service API.
• Choosing data storage strategies and platforms.
• Designing SQL database schemas.

The Assignment

For this assignment (and also for HW6) you will submit architecture design documents for a few kinds of systems.  You may work alone or in pairs (groups of three are not allowed).  If you choose to work alone on both HW5 and HW6 then you may skip half of HW6.  Otherwise (if working as a pair on either assignment) you must design all four architectures.

For each of the systems below, you will create several kinds of documentation for your architectures.  A sample architecture doc is posted here:

Sample Architecture: Meeting Scheduler

Notice, that the document need not be very long.

Your document should include:

• A short description of the high-level product-design decisions you made.  These are choices that refine the basic specification already provided by the assignment.
• An overall architecture diagram.  These should be similar to the sample, those in upcoming Lecture 12 and 13 (the Wikipedia diagram in Lecture 3 is another good example).
• Documentation for each component of the system.  This should include:
  • A short description of the component's functional role or purpose in the system. 
  • On what platform would the component be deployed on AWS?  For example, will you use Elastic Beanstalk, ECS, Lambda, Fargate, EC2, Elastic Map Reduce, etc.?
  • API specifications for any services in your system.  List each of the API "endpoints", indicating the HTTP method, path format, and JSON body posted and sent back, if any.  The "gold standard" for documenting your API would be to use Swagger and then export the single page html documentation and include it in your submission.
  • List the programming language used, runtime framework (eg., Tomcat, Flask, Node.js), and any important 3rd party libraries to be used when implementing each code component.
  • A specification for how data is formatted in any data stores.   For example, if you are using a SQL database, then give an approximate database schema.  As another example, if you are using MongoDB, what is the key and what is the structure of the JSON data?
  • Wireframes (simple design mockups) for any user interfaces.  Keep this simple and don't go into too much detail.  You can draw these by hand and take photos.  Drawings of roughly 3 to 5 screens will probably be enough to convey the idea of your app.  Every feature shown in your UI should be somehow supported by your backend design.

Most of you have never done this kind of design, so it is essential that you come to office hours to discuss your designs to get feedback before turning in your solutions. 

To review and prepare you for the assignment, you might also want to read about Stack Overflow's architecture, though the article goes into a lot of hardware details that are irrelevant if you are deploying to the cloud.

Your architecture should be scalable to tens of millions of monthly-active users.  I am not expecting you to make use of NoSQL databases, because they won't be covered until later in the class.  You can achieve this level of scale with relational/SQL databases.

Architecture 1: Tinyurl

Design an architecture to implement a url shortener like https://tinyurl.com.  This should be pretty simple.

Note that the HTTP protocol has redirection built in.  Your service can just return a 301 redirection to redirect a browser (originally directed to a shortened URL) to go to the final destination.

Architecture 2: A New Social Media, Forum, or Messaging Platform

If you could build a new kind of social media platform, what would it look like?  Maybe you can solve some problems that exist in current platforms?  Please make sure your design is highly scalable.

Your app should notify users of new messages/content even if they are not actively using the app.  Push notifications are covered in Lecture 12.  If you choose to use smartphone push notifications, please remember that these are not 100% reliable.  So, your app should also have a way to request/pull a list of new messages.

Submission

Turn in one big PDF for the team.  As in HW4, only one partner should submit.  The non-submitting partner should submit one line of text naming the partner.  The document should clearly list the authors (including netids).  Remember that you should review your designs with a member of the teaching staff at least once before the deadline.