This course explores advanced topics in highly scalable Internet services and their underlying systems’ architecture. Software today is primarily delivered as a service: accessible globally via web browsers and mobile applications, and backed by millions of servers. Modern web frameworks (e.g., Ruby on Rails, Django, and Express), and continuous improvements to cloud providers (e.g., Amazon Web Services, Google Cloud Platform, and Microsoft Azure) make it increasingly easier to build and deploy these systems.
Despite these advances, building scalable Internet services today still requires an understanding of topics like caching, load balancing, security, and monitoring. In this course we will examine these topics and more: the state of the art in building scalable Internet services.
By the end of this course students will be able to:
write and deploy highly scalable web functions using AWS Lambda
write a modern front end client application using React
measure the performance of various components of a web service
discover and resolve bottlenecks in a web service
All core course topics, covering the essentials of building large scale Internet services, will be presented in the form of pre-recorded videos. Links to the videos and associated material for each topic should be made available at the beginning of the week the topic is covered.
Class will meet twice a week during the scheduled class time unless otherwise mentioned. Students are expected to watch the week’s videos prior to the scheduled class times in order to leverage this time to ask and answer questions, and explore the material in more depth.
These classes will be held via Zoom. The Zoom classes will be recorded and shared only with enrolled students. Students are strongly encouraged, but not required, to turn on their web cameras when speaking and interacting in break-out rooms with their peers.
Should the instructor experience any technical difficulties during synchronous classes, students may check Piazza for updates.
Please read the following UCSB notice regarding class Zoom recordings:
This live Zoom session will be recorded for students who may not be able to attend at this time. By default, your microphone and camera will be muted when you join the session. If you do not want to be included in the recording, simply keep your camera and microphone off. You may ask questions in the chat window. NOTE: Student participants are prohibited from recording of any kind. Only the instructor is permitted to record.
All students are expected to join the class on Piazza as class announcements will be made there. Additionally Piazza is used for offline questions about the class content and its projects. Students are able to submit anonymously, though anonymous content will not be counted toward participation. Students are strongly encouraged to answer each other’s questions by improving upon the “student answer”.
Please create a new post for each distinct question, rather than asking new questions as a follow up to an existing post. Follow-ups are useful to obtain more information necessary to answer a question, or to work through possible solutions to a question.
Piazza is used for one-on-one communication with the instructor for content pertaining to this class. Please do not reach out to the instructor via email, nor Nectir for class related communications.
Nectir is a real-time chat service available to UCSB students and faculty. A
#cs291a_w2021, has been created for this class to support
student-to-student discussion. Initially the
#cs291a_w2021 channel will be
open to all UCSB students, but once the course roster is finalized, the channel
will be made available only to enrolled students.
Additionally, Nectir allows students to create private groups, and direct message others. Private groups can be used to facilitate real-time team communication.
Please do not direct message the course instructor on Nectir for class-related matters. Please use Piazza for such correspondance.
Once the primary project has started in week 5, teams will meet with the instructor once each week, via Zoom. These meetings will be scheduled for approximately 15 minutes.
There will be four projects in the first five weeks of the course, one per week with the fourth project spanning two weeks. These projects will ensure students have the basic knowledge to build and deploy modern, simple, and scalable web services without needing a deep understanding of how the underlying systems enable scalability. The first three projects are to be completed individually, and the fourth completed as a pair.
The goal of the course’s primary project is for students to experience and resolve pain points encountered when building and deploying a moderate-sized scalable web service. Students will do this using some of the latest web technologies in order to learn how to tackle scalability and fault-tolerance concerns. Projects will be conducted in agile teams of four to six students, and each team will build their own scalable web site using fundamental web technologies and the Ruby on Rails framework. A team may not be comprised of more than two undergraduate or BS/MS students.
|3||Project 0 (Static Web Page)|
|6||Project 1 (AWS Lambda)|
|9||Project 2 (Google’s Cloud Run)|
|12||Project 3 (Chat Server and Client)|
|65||Primary Project Individual Score|
Participation is an important part of keeping a class engaging. Participation can be earned by asking or answering questions during synchronous classes, and asking or answering public questions on Piazza. Note that neither private conversations with the instructor, nor participation during team check-ins count toward the participation score.
Projects 0 through 3 are scored as either complete (
100%) or incomplete
0%); there is no fractional score other than as described below for late
Late submissions incur a
1% penalty for every five-minutes late rounded up.
For example, if the deadline is before
2pm, an assignment submitted at
14:00:00 (5 minutes late) will receive
99% of its score, and an assignment
15:00:00 (65 minutes late) will receive only
87% of its score.
A project’s score is primarily based on the team’s description of their iterative approach to load testing and scaling their web service as described in their project report and highlighted in their project video. Objectively these components break down into:
|60||iterative approach to load testing and scaling|
|20||web service complexity|
|10||quality of project report|
|10||quality of project video|
The individual score is computed by multiplying the project score by the student’s peer score. Peer scores are computed by summing the relative percent of work each individual’s teammates confidentially assigns them.
For example, a three person team may assign the following peer scores:
The observations from the data in the table above are:
55%) as having contributed more work than Chuck (
60%) contributed more work than Chuck (
52%) contributed slightly more work than Bob (
With these values, Alice’s peer score would be
85%. With a project score of
95%, Alice’s Primary Project
Individual Score would be
97.85%, and Chuck’s
We will confidentially conduct the peer score process twice during the course:
The first peer score is intended to help students see if they need to make any adjustments to their team contributions. Only the outcome of the final peer score will be used to compute an individual’s score. Any moderate deviations of more than two points from equal contribution will require justification, and may be followed up on by the instructor.
Letter grades will be assigned as follows:
The number listed is the lower bound of the percent grade for the given
range. It is expected that each person is a relatively equal contributor on
their team, with the exception that there may be significant positive
outliers. Additionally, it is expected that each team does a solid job on their
project. As a result, please note the drop to an
F grade immediately