COMPSCI 426 Syllabus, Spring 2027

Spring 2027. This is a draft syllabus: the Summer 2026 course mapped onto a full 14-week in-person semester. Staff, office hours, rooms, and the dated calendar for Spring 2027 are posted on Canvas when the term opens; where Canvas and this page differ, Canvas is the one to follow.

Number: COMPSCI 426
Title: Scalable Web Systems
Instructor: Tim Richards
Semester: Spring 2027
Mode: In-person
Scheduled Meetings: Lecture twice a week. Days, times, and rooms are on SPIRE.
Exams: There are no exams in this course
Groups: There is group work in this course
Credits: 3
Prerequisites: COMPSCI 320 or COMPSCI 326 with a grade of C or better. If you are from another academic institution or have unique circumstances, you must submit an override request to be considered for enrollment.

Description

The web has become a large and complex area for application development. Access to an abundance of open source languages, libraries, and frameworks has led to the quick and easy construction of a variety of applications with several moving parts working in coordination to present to the user the illusion of a single program. In reality, web applications are extremely difficult to get right. They involve a large collection of coordinated services, multiple databases, complicated user interfaces, security and performance issues, and ever changing third party services, spread across physical and virtual machines. These complications are further stressed by the large number of concurrent users that access these applications every second. This course investigates several well known web-based applications and the technology and software architecture used to scale them. We will also study specific topics related to scalability in software design in the context of web application architecture. This course is hands-on and heavily project-based; students will build, monitor, and load test a distributed system composed of coordinated services. This course counts as an Elective for the CS and INFORM Majors.

This course is concept-first and experiential. You will build and break real scalable systems before we put names to the patterns you discover. The vocabulary of the field, sidecars, ambassadors, sharding, scatter/gather, comes after you have already felt why each pattern exists.

Staff

Instructor: Tim Richards
Email: tdr@umass.edu, for the record only. Course questions go through the Canvas Inbox; see Communication.
Teaching assistants and undergraduate course assistant: listed on Canvas when the term opens.
Office hours: posted on Canvas in the first week.

Learning Objectives

By the end of this course, students will be able to:

Configure and use a devcontainer-based development environment with Docker and VS Code for a reproducible, team-consistent workspace.
Explain the core properties of distributed systems, including latency, reliability, idempotency, and delivery semantics, and reason about the trade-offs between them.
Containerize an application with Docker and orchestrate multiple coordinated services with Docker Compose.
Apply single-node patterns, including the sidecar, ambassador, and adapter patterns, to extend services without modifying them.
Design and reason about serving patterns, including replication, caching, sharding with consistent hashing, and scatter/gather.
Measure system behavior under load using k6, and interpret latency percentiles, throughput, and error rates.
Build event-driven and queue-based systems, including work queues, pub/sub pipelines, and dead letter queues.
Reason about distributed coordination, including locks, leases, ownership election, and concurrent data manipulation.
Instrument a system for observability using structured logging, metrics, and tracing.
Diagnose common distributed failure patterns, including thundering herd, versioning errors, and cascading failure.
Use Git and GitHub for version control, branching, and pull request workflows on a shared team repository.
Plan, build, and present a complete, scalable web system simulation as a team.

Time Commitment

Plan for roughly nine to ten hours a week, steady across the semester.

UMass Amherst defines course workload by a standard credit hour rule: forty five hours of work per semester for each unit of credit. By that rule a three credit course represents at least 135 hours of total work across the term, which comes to about nine to ten hours a week. About two and a half of those hours are the two weekly lectures; the rest is knowledge-unit work, homework, and your team’s sprint work.

Because each unit builds directly on the one before, and because this is a systems course where one misconfigured service can block everything downstream, the work does not compress well into a weekend burst. The quizzes are the clearest early signal of whether you are keeping pace. If you find yourself consistently spending far more than this, or far less and still finishing everything, let me know: that is useful feedback on the course and may be a sign we should look at how you are approaching the work.

Course Structure Synopsis

Course Delivery

This course is in-person, with lecture twice a week, and it blends those meetings with hands-on, self-paced knowledge-unit work. Lecture is not where the material is delivered to you for the first time. You read the knowledge unit before the lecture on it, and we spend the time together clearing up what did not land and building something with it. The next section describes exactly how a meeting runs. All course materials, including the full text of every knowledge unit, remain available on Canvas at any time; homework, quizzes, and sprint work are completed on your own schedule within the posted deadlines. This course is designed to be experiential, meaning that you will learn by doing, and the course structure is built around active participation and hands-on activities, including in-person ones.

What a Class Meeting Looks Like

Every lecture follows the same four-part shape, so you always know what is coming. The whole thing rests on one assumption: you have read the knowledge unit before you walk in. Seventy-five minutes is not enough time to both deliver a unit and do anything with it, so we use the time for the part that is genuinely hard to do alone.

Reading check, and what it showed, about 30 minutes. A handful of short questions on the unit, due at 8:00 AM on the morning of that unit’s lecture, so I can read your answers before class. It is graded on completion, not correctness, so an honest wrong answer is worth exactly as much as a right one. Every check ends by asking what did not make sense, and what you write there is what I open the class with. Guessing what I want to hear makes the class worse for you specifically.
In-class activity, about 30 minutes, in pairs. A small build with a real design decision in the middle of it, one where reasonable people disagree. You work in pairs, one driving and one navigating. See below for what is and is not expected here.
Discussion, about 10 minutes. We compare what different pairs decided and tie it back to the sprint your team is building.
Exit ticket, about 5 minutes. A few short questions submitted in Canvas before you leave. See below.

The in-class activity is not graded and nothing is submitted for it. The brief for each one is posted in Canvas under its unit, and it opens when that lecture starts. There is no submission box, no points, and no due date. It is there so you and your partner have the brief and the starter code in front of you while you work, and so you can go back to it afterwards. It is meant to be done during class, with a partner, not finished at home alone; the disagreement with your partner is the part that teaches you something, and you cannot have that by yourself later.

What you did in the activity is reported in the exit ticket. The exit ticket is a short set of questions that opens for the last fifteen minutes of class and closes five minutes after class ends, and it is where the activity actually gets recorded. It is deliberately not open before that, so that nobody spends the activity filling in the form instead of doing the work it asks about. It asks who your partner was, the word shown on the screen during class, a question about that day’s activity, and whether anything is still confusing, a question you did not get the chance to ask, or anything else you want me to know. Every answer to that last one is read before the next class. Everyone submits their own; it is not one per pair. It counts toward the Exit Tickets category, it is graded on completion rather than correctness, and because it can only be answered from inside the room it is also how attendance is taken.

Exit tickets cannot be made up, including if you forgot to press submit, unless you have a documented excused absence. If something comes up, message me through the Canvas Inbox rather than letting it pass.

Knowledge Units (KUs)

The primary way in which learning takes place is through knowledge units (KUs). Each KU is a self-contained module that includes preparatory reading, hands-on activities, and exercises. You are expected to complete each KU in order, as they build upon one another. The course is deliberately concept-first: most units ask you to build or observe something before the underlying pattern is named, so that the name lands on an experience you already have rather than on an abstraction. Each KU will have a set of activities that you must complete, including coding and load-testing exercises.

Canvas

Canvas is where you will find links to all of the course material. The syllabus and schedule can be found on Canvas. All assignments will be posted on Canvas. Grades will be posted to Canvas. Announcements will be posted on Canvas. If in doubt, go to Canvas to find what you are looking for and follow links from there.

Gradescope

Homework assignments are submitted through Gradescope and graded automatically. When you submit, an autograder runs your code against a test suite and reports a score immediately; you do not have to wait for manual review to see how you did. If a test fails, the output includes enough information to diagnose and fix the issue before the deadline. You may resubmit as many times as you like before the deadline, and only your final submission is graded. Gradescope is accessible through Canvas.

Communication

All course communication happens through the Canvas Inbox. Do not send email directly to the instructor or to the course staff. Administrative questions go to the instructor alone. Questions about the course material go to the entire course staff, so that whoever is free first can answer. Answers worth the whole class seeing are posted to a Frequently Asked Questions page on Canvas and kept up to date. See the full Communication section below for how to address a message and what to put in it.

Spire

Final grades will be posted to Canvas before they are submitted to Spire. You are expected to check your grades in both places to ensure that everything adds up. You are responsible for ensuring that your grades are accurate and that you have received credit for all assignments that you submitted by the posted deadline. If you notice any discrepancies, you should contact the course staff immediately.

Required Books, Equipment, and Technology

One textbook, one container that carries the entire stack, and a machine capable of running it.

This course uses one textbook: Designing Distributed Systems, 2nd Edition, by Brendan Burns (O’Reilly). You have free access to the book by logging in using your UMass credentials under “Other login options” and selecting “Affiliated with a school or institution?” The book frames containers as the vehicle for every pattern we study, and its treatment of patterns like the sidecar, the work queue, and dead letter queues is unusually thorough. Preparatory reading for the Knowledge Units draws directly from it. Beyond the textbook, everything you need to read is provided through as Knowledge Units, primers, and linked documentation. Where you need a reference for a specific tool, the course points you to that tool’s official documentation.

What this course also requires is a computer you control and that is capable of running a containerized development environment. You need a reasonably current laptop or desktop running macOS, Windows, or Linux, with enough memory and disk space to run Docker comfortably; eight gigabytes of RAM is a practical minimum and sixteen is more comfortable, along with several gigabytes of free disk space for container images and your project. A Chromebook or a tablet is not sufficient for this course, because neither can run the local development environment. If your only computer cannot meet these requirements, send me a Canvas Inbox message during the first few days so we can help you find an alternative such as a loaner machine through the University. We will try, but we can’t guarantee.

Nearly all of the software for this course is delivered through a single prepared development environment, a Dev Container that bundles the entire technology stack so you do not have to install or configure each piece by hand.

Development Environment

This course uses development containers (devcontainers) to provide a uniform and consistent development environment for all students. Devcontainers are a way to package and distribute development environments using Docker containers. This allows you to have a consistent environment across different machines and operating systems, and ensures that you have all the necessary tools and dependencies installed.

You are not required to know much about Docker or devcontainers to begin, but you will need to have Docker installed on your machine, and over the course of the term you will come to understand containers deeply, since they are the central building block of the entire course. You will be required to use the devcontainer for all course-related work, including coding exercises, load tests, and the project.

The core software you will need to install is VS Code, Docker Desktop, and the VS Code Remote Containers extension. The devcontainer is configured to include the tools and dependencies for the course, including Node.js, npm, the Docker CLI and Compose, the k6 load testing tool, and Caddy as a reverse proxy and load balancer. Services and worker processes in this course are written in Node.js and JavaScript. You should not install this software right now, as you will be instructed on how to do so as part of the course setup unit.

Assignments

We use several different methods to scaffold your learning and assess your understanding of the material covered in this course. We outline the various methods and the kind of assessment below so you can better understand and plan your learning path. We categorize assignments as either being formative (F), summative (S), or a combination (FS). A purely formative assignment is designed to build your understanding, low stakes, and doesn’t have any or very little impact on your grade. A summative assignment is designed to measure your understanding of the material. A combination of formative/summative contains aspects of low stakes assessment with measurement.

		Assessment Type	Count	Weight
Exercises	Short practice exercises built into each KU	F	many	0%
Participation	Discussions, reflections, and team status reports	F		4%
Exit Tickets	In-class work, one per lecture, lowest three dropped	F	~26	8%
Reading Checks	Before each unit’s lecture, lowest two dropped	F	18	5%
Quizzes				13%
	Quiz	F	6
Homework				25%
	Homework	FS	4
Sprints				25%
	Sprint 0: Team Formation and Project Concept	F	1
	Sprint 1: Project Definition and Scalability Framing	FS	1
	Sprint 2: First Containerized System	FS	1
	Sprint 3: Serving Patterns and First Load Test	FS	1
	Sprint 4: Async Processing and Resilience	FS	1
Project				20%
	GitHub Repository URL	S	1
	Recorded Video Demonstration	S	1
	Project Poster	S	1
	Reflection	S	1

Exercises

Practice embedded in every unit, not graded, but expected.

Exercises are short activities built into each Knowledge Unit. They are not submitted and they do not count toward your grade. Many ask you to run a service under load with k6, observe a latency percentile or an error rate, and interpret what you see. The goal is practice: try something, get it wrong safely, and learn from it. You are expected to do the exercises; they exist to make the hands-on work in the Knowledge Units land rather than to generate a score.

Participation

Small, low-stakes tasks spread across the term that keep you engaged with the course and your teammates.

Participation tasks appear throughout the weekly modules and take a variety of forms: an introduction discussion before teams form, short reflection surveys connecting a unit to your own experience, and brief team status reports during the project weeks. They are not timed and not difficult; the expectation is simply that you show up and engage. Each task is graded on completion, not correctness or length. Together, participation tasks make up four percent of your final grade.

Exit Tickets and Reading Checks

Prepare before class, do the work during it.

Exit tickets: eight percent. The exit ticket you submit at the end of each lecture is its own category. It is not a score for being in the room. It records the in-class work: who you paired with, and what your pair decided and why. Showing up and not doing that work does not earn it. Because it can only be answered from inside the room, it is also how attendance is taken.

The lowest three are dropped automatically, for everyone, with no reason needed and nothing to request. That covers illness, an interview, a bad morning, and a phone that would not submit. Beyond three, each further miss costs a little, so an occasional absence stays cheap. What it will not survive is not coming: this course is built around what happens in the room, and a grade that says you mastered it without ever being there would not be telling the truth.

Reading checks: five percent. The short check due at 8:00 AM before each unit’s lecture is also its own category. It is graded on completion, so an honest wrong answer scores exactly what a right one does, and the whole thing takes about five minutes. The lowest two are dropped automatically, same as the exit tickets and for the same reasons.

Together these two categories are thirteen percent of your grade, which is a deliberate statement about where the learning in this course actually happens.

Quizzes

A timed check on the preceding two weeks’ material, taken at your own pace in the days after that block closes.

Roughly every other week you complete a timed quiz covering the knowledge units since the last one. Each quiz is multiple choice, and you have a fixed time per attempt. You may take each quiz up to three times; your highest score is recorded. The last quiz is cumulative across the full course. Together the six quizzes make up thirteen percent of your final grade. Quizzes are available on Canvas.

Homework

Four hands-on assignments that build the skills the project depends on.

There are four homework assignments across the term, one every two weeks from Week 2 through Week 10. Each is a hands-on task that involves creating parts of a simulated distributed system using real tools and services: k6 for load testing, JavaScript for building services, and existing services such as Caddy, Redis, MongoDB, PostgreSQL, Prometheus, and Grafana. Homework is submitted through Gradescope and graded automatically against a rubric; you will see your score as soon as the autograder runs. Together the four assignments make up twenty-five percent of your final grade. Your scores from Gradescope will be periodically synced to Canvas.

Sprints

A simulated scalable system built incrementally: each sprint applies only what the units so far have covered.

The Sprints are the team project itself, carried forward in stages rather than assembled at the end. Each sprint is due once the Knowledge Units that inform it are covered, so the system grows in lockstep with the course material. You cannot design the full architecture at the start; you do not yet know the patterns. Instead the simulation is extended one layer at a time: Sprint 0 forms the team and stakes out a domain idea; Sprint 1 frames the scalability problem using the distributed systems vocabulary from the first units; Sprint 2 produces the first containerized services running under Docker Compose; Sprint 3 adds serving patterns (replication, caching, load balancing) and a first k6 load test; Sprint 4 introduces async processing and resilience; and Sprint 5 instruments the system with observability, runs a final load test, and delivers the four capstone artifacts.

The system you build throughout is a simulation: data is synthetic, latency is injected, failures are scripted, and computation is modeled. This is a deliberate choice, not a shortcut. Building a production system from scratch in one semester is not realistic, and the goal of this course is not deployment; it is design, engineering, and measurement. Simulation lets you practice every pattern the course covers, instrument and break the system intentionally, and measure it under realistic load, without the operational complexity of real data pipelines or live traffic. The skills you develop, structuring services, reasoning about coordination, interpreting latency percentiles, are the same ones a team would use on a real system.

Sprints introduce no new instruction. They are where you apply the current state of the Knowledge Units to the simulated system your team is building. Teams are assigned by the instructor and are 3 to 4 members. Each team has a TA as its liaison: questions about your team’s code or repository go on GitHub, as an issue or a pull request comment that mentions your liaison, and problems within the team go to your liaison in a private Canvas message. Because this course has no separate lab sequence, the professional workflow skills that labs would otherwise carry, clean commits, pull requests, code review, conflict resolution, are practiced and assessed directly inside the sprints. Because impressions are unreliable, your sprint contribution is assessed against objective GitHub evidence, your commits, the pull requests you authored and reviewed, and the merge history, rather than against anyone’s sense of who did what. Sprints 0 and 1 are half-weight (each worth half a full sprint); Sprints 2, 3, and 4 are full-weight. Sprint 5 is graded as the Project Final (20%) rather than as part of the Sprints category.

Sprint 0: Team Formation and Project Concept, due early in Week 2

Week 1 covers setting up the development environment and GitHub. Sprint 0 is about getting organized as a team and staking out a project idea while that setup is still fresh. No architecture decisions are required yet; students do not have the vocabulary for them.

Shared GitHub repository created with all team members added as collaborators
README with team roster
A short paragraph describing the domain the team wants to simulate and a first guess at what makes it interesting from a scalability standpoint: what would a real system in this domain need to handle that a single server could not?

Sprint 1: Project Definition and Scalability Framing, due end of Week 4

Units 01 to 03 cover why distributed systems exist, the core trade-offs between latency and reliability, and the semantics of idempotency and message delivery. Sprint 1 asks the team to apply that vocabulary to their chosen domain. No code is expected yet; this is design thinking grounded in the concepts just studied.

A refined project description: what domain, what scalability problem, and why this problem is meaningful (the Computing for the Common Good framing)
An initial list of services the simulation might include, with one sentence on what each does; this is a first guess, not a commitment, and it will evolve as more patterns are introduced
A short statement of the system’s latency and reliability requirements: what does “fast enough” mean for this domain, and what happens if a component fails?

Sprint 2: First Containerized System, due end of Week 7

Units 04 to 07 cover Docker fundamentals, Docker Compose, the sidecar pattern, and the ambassador pattern. Sprint 2 is the first time the team writes code. The goal is a multi-service simulation running under Docker Compose with at least one of those patterns applied.

At least two services containerized and running under Docker Compose, each with its own HTTP endpoint returning domain-relevant simulated data
At least one sidecar or ambassador pattern applied alongside a primary service as a separate container
A docker-compose.yml committed to the repository that starts the whole system with a single command

Sprint 3: Serving Patterns and First Load Test, due end of Week 9

Units 08 to 11 cover the adapter pattern, replicated services with load balancing and caching, sharded services, and scatter/gather. Sprint 3 extends the existing simulation with at least one serving pattern and adds the first measurement.

At least one service running with multiple replicas behind Caddy as a load balancer
A caching layer (Redis) integrated into at least one service path, with simulated cache hits and misses
A k6 load test script that exercises the replicated service, with a written summary of the p50, p95, and p99 latency results

Sprint 4: Async Processing and Resilience, due end of Week 11

Units 12 to 15 cover resilience and failure modes, event-driven processing, work queue systems, and pub/sub pipelines. Sprint 4 adds an asynchronous processing path to the simulation and introduces controlled failures to show the system can handle them.

At least one async processing path: a work queue or pub/sub channel backed by Redis
Health check endpoints on all services, wired into Docker Compose healthcheck configuration
At least one scripted failure scenario: a service that can be made to fail or slow down, with a brief written description of how the system responds

Sprint 5: Observability, Final Measurement, and Delivery, due at the end of the term

Units 16 to 18 cover coordinated batch processing, ownership election, and observability. Sprint 5 instruments the simulation, produces the final load test evidence, and assembles the four capstone deliverables.

Prometheus metrics exposed by all custom services, scraped by a Prometheus instance defined in Docker Compose
A Grafana dashboard showing at minimum: request rate, error rate, and p95 latency for the main service path
Structured JSON log output from all custom services
A final k6 load test with a written interpretation: what the latency distribution shows, how it compares to the Sprint 3 baseline, and where the bottleneck appears to be
GitHub repository URL: code committed, README complete, system starts with a single command
Recorded video demonstration (10 minutes or less): the system starting with docker compose up, at least one endpoint responding, the Grafana dashboard live during a k6 load test, and an explanation of one design decision and its trade-off
Project poster: the problem, the architecture, the patterns demonstrated, and the key trade-offs, formatted as a one-page PDF
Individual reflection: submitted separately by each team member covering what you contributed, what you learned, and what you would do differently

Project

The capstone: a simulated scalable system that demonstrates the design, engineering, and measurement skills of the course.

The Project is the summative destination the entire course is aimed at. Working in a team, you choose a problem domain in the spirit of Computing for the Common Good and design a meaningful but achievable scalable application. You then build a simulation of that application: services that model realistic behavior using synthetic data, injected latency, and scripted failures, orchestrated with Docker Compose and measured under load with k6. The simulation is not a stripped-down version of a real system; it is the full architecture, with coordinated services, asynchronous pipelines, caching, and observability, implemented in a way that makes every pattern visible and every failure intentional. The goal is to demonstrate that you understand how such a system is designed, how its components interact, and how its behavior changes under load.

You submit four deliverables: the source code in your shared GitHub repository, a recorded video walkthrough of the running system, a poster presenting the problem, the architecture, and the trade-offs you made, and an individual written reflection from each team member on their own contribution and what they learned. You are assessed on collaborative practice, on meeting the sprint deliverable deadlines that pace the project from Week 1, and on professional conduct throughout, with contribution again read from objective GitHub evidence and the grade trajectory-weighted across the term. Deployment to a public host is not required and is not taught here; the destination is a complete, multi-service simulation running under Docker Compose in the dev container and demonstrated on video.

Schedule

The course runs across the 14 instructional weeks of the Spring 2027 semester. The dated calendar, with every due date, spring break, and holidays, is posted on Canvas when the term opens. The plan below is the shape: two knowledge units a week to match the two weekly lectures, a homework every two weeks, a quiz roughly every other week, and a sprint due each time the units it needs are done.

All 18 units are covered by Week 10. Weeks 11 through 14 carry no new units or homework: they are for the team project.

Markers: (A) assigned, the team or the individual assignment can start, since the units it needs are done; (D) due. Sprint 0 is the exception, assigned on day one, since it is just team formation.

Week	Units	Assignments
1	0A Development Environment Setup; 0B GitHub and Team Setup	Sprint 0 (A)
2	01 Why Distributed Systems? Patterns, Trade-Offs, and the Design Mindset; 02 Core Concepts: APIs, Latency, Reliability, and Percentiles	Sprint 0 (D), Sprint 1 (A), Homework 1 (A)
3	03 Idempotency, Delivery Semantics, and Data Consistency; 04 Docker Fundamentals	Quiz 1
4	05 Docker Compose; 06 The Sidecar Pattern	Sprint 1 (D), Homework 1 (D), Homework 2 (A)
5	07 The Ambassador Pattern; 08 The Adapter Pattern	Sprint 2 (A), Quiz 2
6	09 Replicated Services: Stateless Scaling, Caching, and Rate Limiting; 10 Sharded Services: Consistent Hashing and Partitioning	Homework 2 (D), Homework 3 (A)
7	11 Scatter/Gather; 12 Resilience and Failure Modes	Sprint 2 (D), Sprint 3 (A), Quiz 3
8	13 Functions, Event-Driven Processing, and the Decorator Pattern; 14 Work Queue Systems	Homework 3 (D), Homework 4 (A)
9	15 Event-Driven Batch Processing: Pub/Sub, Kafka, and Pipelines; 16 Coordinated Batch Processing	Sprint 3 (D), Sprint 4 (A), Quiz 4
10	17 Ownership Election: Locks, Leases, and Consensus; 18 Observability: Metrics, Tracing, Dashboards, and Alerts	Homework 4 (D)
11	No new units, project work	Sprint 4 (D), Sprint 5 (A), Quiz 5
12 to 13	No new units, project work	Quiz 6, cumulative, in Week 12
14	Project deliverables	Sprint 5 (D) at the end of the term

Grades

All grades will be recorded and available in the Canvas Gradebook. Make sure you check your grades on a regular basis to ensure that they are correct. Assignments that are submitted to Gradescope will show your grade in Gradescope. Periodically those grades will be migrated into Canvas. This is a manual process, but we will try to do this on a regular basis.

Grading Scale

The number you earn maps to a letter with no curve and no surprises.

Final grades are computed from the weighted categories in the Assignments section and converted to a letter using the scale below. Grades are not curved. Your final percentage is rounded to the nearest whole number once, at the end of the term, so an 89.5 becomes a 90 and an 89.4 does not.

Letter	Range	Letter	Range
A	93 to 100	C	73 to 76
A-	90 to 92	C-	70 to 72
B+	87 to 89	D+	67 to 69
B	83 to 86	D	60 to 66
B-	80 to 82	F	below 60
C+	77 to 79

This is a three credit course, and the grade you earn carries the same weight toward your degree and your GPA as any other three credit course. There is no extra credit.

Communication

One channel, the right recipients, enough detail to get a useful answer on the first reply.

All course communication happens through the Canvas Inbox, the messaging tool built into Canvas. Do not send email directly to the instructor or to any member of the course staff. The addresses in the Staff section are listed for the record; they are not the way to reach us about this course, and a message sent to them may go unanswered.

The reason is not preference. Canvas keeps every course conversation attached to this course and in one place, which means a question does not get buried under the rest of a working inbox, any of us can pick up a conversation the others have already seen, and there is a single record to check when a question about a deadline or a grade comes up later. Email does none of that.

Who to address the message to

This is the part that decides how fast you get an answer, so it is worth getting right.

Administrative questions go to the instructor alone. Deadlines and extensions, grades and rubrics, enrollment, teams, accommodations, illness, and anything personal or private belongs in a message addressed only to me.
Questions about the course material go to the entire course staff. Add me and every TA and UCA listed in the Staff section as recipients. The dev environment, Docker and Compose, k6, Git and GitHub, the knowledge units, homework content, and debugging your own code all belong here. Addressing all of us is not noise; it means whoever is free first answers you, which is almost always sooner than waiting on any one person.
Questions about your team project’s code or repository go on GitHub. Open an issue or comment on the pull request and mention your team’s liaison by their GitHub username; problems within your team go to your liaison in a private Canvas message. The liaisons are announced on Canvas once teams are set.

If you are genuinely unsure which one a question is, send it to the whole staff. Nobody will mind, and I will move it if it turns out to be something private.

How to send one

Open Inbox from the global navigation on the left edge of Canvas, click the compose icon, and choose this course. To reach the whole staff at once, click the address book icon beside the To field and pick the Teachers and Teaching Assistants groups rather than typing names one at a time.

Turn on notifications so you see a reply. Under Account, then Notifications, set Conversation Message to notify you immediately. Canvas will then tell you when a reply arrives, which is the one piece of setup this whole arrangement depends on.

What to put in it

Give the message a specific subject line naming what it is about, for example Sprint 3 Caddy load balancing question or Unit 10 consistent hashing question, rather than Question or Help. A specific subject line is also what makes a conversation findable weeks later, by you as much as by us.

In the body, name the deliverable exactly, Sprint 3 or Unit 11 rather than a vague reference. For questions about the material, your code, or a grade, paste direct links to your repository and to the specific pull request, commit, or failing run. Copy any error message verbatim rather than describing it, and tell us what you have already tried so we do not suggest it back to you. End with the precise question you want answered.

Answers the whole class needs

When a question turns out to be one that many of you have, the answer does not stay in a single conversation. It goes on the Frequently Asked Questions page on Canvas, which is updated regularly through the term. Check it before you write, especially in the days before a deadline: your question may already be answered there, and reading the answer beats waiting for one.

Timing

Reach out early. A message about a deadline, an accommodation, or a situation that may affect your work should arrive before the deadline passes, not after. The staff aim to respond within one business day on weekdays; do not expect responses on weekends or University holidays.

Course Policies

Engagement, late work, incompletes, and exemptions.

This course has two scheduled lectures a week, and attendance, recorded by the exit ticket, is part of your grade. The course also moves steadily: each unit builds on the one before it, and because this is a systems course, one misconfigured or missing service can block everything downstream. Your engagement is measured by showing up, by the on time completion of reading checks, quizzes, and homework, and by steady, visible contribution to your team’s sprint work in GitHub.

Late work is handled differently depending on what kind of work it is. Homework assignments may be turned in late for up to two days past the due date, with a deduction of ten percent per day; after two days they are no longer accepted and are scored as zero. Sprint deliverables and the final capstone submission are hard deadlines and are not eligible for the late allowance, because your teammates and the staff depend on that work being in place on time and because the schedule has no slack to absorb a slipped project milestone. If something is going to prevent you from meeting any deadline, send me a Canvas Inbox message requesting an extension before the deadline passes. Proactive communication is the rule in this course, not a courtesy. We are far more able to help a student who writes before the deadline than one who writes after it.

Incomplete grades follow university policy. An Incomplete (INC) may be granted only when a student who has been in good standing and has completed a substantial portion of the coursework is prevented by serious circumstances beyond their control from finishing on time. An Incomplete is never a substitute for a low grade and must be arranged with the instructor through a written agreement before the end of the term that specifies the remaining work and the completion date.

There are no exemptions from individual assignments. Every student completes the same work, with the single exception of arrangements made through Disability Services or for documented religious observance, both of which are described in the sections below.

Academic Honesty and Collaboration

What honest work looks like here, what counts as collaboration, and how to disclose AI use.

This statement is required by the University and is reproduced verbatim. Since the integrity of the academic enterprise of any institution of higher education requires honesty in scholarship and research, academic honesty is required of all students at the University of Massachusetts Amherst. Academic dishonesty is prohibited in all programs of the University. Academic dishonesty includes but is not limited to: cheating, fabrication, plagiarism, and facilitating dishonesty. Appropriate sanctions may be imposed on any student who has committed an act of academic dishonesty. Since students are expected to be familiar with this policy and the commonly accepted standards of academic integrity, ignorance of such standards is not normally sufficient evidence of lack of intent. For more information on the process and resolution of complaints, contact the Academic Honesty Office, 511 Goodell, (413) 577-6767, honesty@umass.edu.

Because this course is built around team projects, it helps to be explicit about where collaboration is expected and where it is not. Within your own project team, collaboration is the point: you share a repository, you co design, and you build together. Across teams, and on all individual work such as quizzes, homework, and the individual written reflection in the capstone, the work you submit must be your own. You may discuss concepts with classmates, but you may not copy another student’s code or homework submissions, and you may not share your own for copying. Submitting another person’s work as your own, or handing your work to someone else to submit, is facilitating dishonesty and is treated as a violation.

AI Statement

AI is a tool you may learn with. It is not a tool that does your work.

You are here to build real fluency with web programming. That fluency comes from writing code, reading error messages, tracing a problem to its source, and getting to a solution yourself. An AI that produces the work for you skips exactly that, and leaves you with something you cannot explain and a skill you did not build.

So the rule for this course is simple, and it holds everywhere:

No AI may write code, prose, or designs that are being evaluated. Not on homework, not on your team project, not on the poster or the video or the reflection. Not if you retype it in your own words afterward. There is one exception, for parts of a project that no rubric line assesses, and it has its own section below.

Everything below is about what AI may do, which is more than you might expect.

The levels

Every assignment in this course is tagged Level 0, 1, or 2. The level tells you what an AI tool is allowed to contribute. Level 3 is not a tag on an assignment; it is a carve-out you can declare inside a sprint or the project, described further down.

Level	What AI may do	What it may never do
Level 0: No AI	Nothing. Do not use an AI tool on this.
Level 1: General questions	Answer general questions about JavaScript, Express, HTTP, Git, or any other topic the course covers.	See your code, your error output, or the assignment text.
Level 2: Show and critique	Look at work you already wrote and tell you what is wrong with it or how it could be better.	Tell you what to write.
Level 3: Unrestricted, on declared support work	Anything at all, including writing the code, but only on parts of a project that you have declared and that no rubric line assesses.	Touch anything a rubric assesses, or go undeclared.

This course never goes above Level 2 on anything being evaluated. Higher levels exist in the wider world, where AI writes code that ships. That is real professional practice and you will meet it. You are not going to meet it here, on the work that is assessed, because this course exists to build the judgment that makes that practice safe, and you cannot build it by skipping it. Level 3 is the deliberate exception and it is narrow: it applies only to parts of your project that are not being assessed at all.

Which level am I at?

Two questions. Ask them in order.

Did the AI produce anything specific to my assignment? Code, prose, a structure, a plan, a diagram. If yes, you are above Level 2 and above what this course permits, whether or not you typed it out yourself.
Did the AI look at my work, my error output, or the assignment? If yes, that is Level 2. If no, that is Level 1.

Question 1 is the one that matters. “Specific to my assignment” is the whole test.

Asking “how does a Docker Compose healthcheck work?” is general. Writing the canonical few lines afterward is fine, because there is only one way to write them and you now know it. Asking “write the healthcheck for my queue worker” is specific, and so is “give me the steps to build this assignment.” Typing out the answer yourself does not change that.

Where each level applies

Assignment	Level
Quizzes 1-6	Level 0
Homework 1 and 2	Level 1
Homework 3 and 4	Level 2
Sprints 0-5, including README, diagrams, and load test write-ups	Level 2
Project: repository, video, poster, reflection	Level 2
Reading checks and exit tickets	Level 0
Discussions, reflections, and status reports	Level 2

Homework 1 and 2 are stricter on purpose. At that stage, reading an error message and working out what caused it is the skill being built. So on those two, describe your problem in your own words if you want to ask about it. Do not paste your code or your error output. That restriction lifts at Homework 3.

Editor autocomplete

Turn it off for coursework. GitHub Copilot, Cursor’s tab completion, and anything like them write code directly into your file, which is above this course’s ceiling on every assignment.

This is the item most likely to catch you out, because these tools are on by default and easy to forget about. If you use one for work outside this course, disable it for this repository, or use a separate editor profile.

What you do not need to worry about

Some things are not covered by any of this:

Seed data, fixtures, sample content, boilerplate config, and code formatting. None of these build a skill this course assesses. Generating forty rows of plausible test data is fine. Generating the code that reads them is not.
AI answers that arrive without you asking, like search-result summaries or an AI-written answer on a forum. Treat them as ordinary sources. You do not need to disclose reading one, but see “Facts are yours” below.
Anything covered by an accommodation. See below.

Level 3: parts that are not being evaluated

Your project will end up containing things that make it work but that no rubric line asks about. Something that sends a mail. Something that turns an address into coordinates. A deploy configuration, a one-off script that imported your starting data, a scheduled job. These are real engineering, they are often the interesting part, and none of them is a skill this course measures.

On those parts you may use AI however you like, including having it write the whole thing. Ask it to design the integration, generate the client, explain the API, write the config. There is no restriction and no ceiling, and using it that way is never academic dishonesty here.

What makes this workable is the boundary, so the boundary is strict:

If a rubric criterion covers it, it is not Level 3. Every sprint and every project artifact publishes its rubric with the assignment, before you build. Read it. Your services and their Compose wiring, your serving and async patterns, your caching and queues, your load tests and how you interpret them, your observability, your README and system diagram, your video and poster and reflection: all assessed, all capped at Level 2. Level 3 is what is left over.
You declare it, before it is graded, in writing. In your own ai-disclosure/ file, list each part: what it is, where it lives in the repository, what job it does, why no rubric line covers it, and what the AI did. Mark it in the code too, with a comment at the top of the file, so whoever reads it knows without cross-referencing.
It earns you nothing. It is not assessed, so there are no points in it. It does not count toward Individual Contribution Evidence, and it cannot be the decision you write up for Design Decision and Trade-off, because you did not make that decision. A sprint where your only contribution is Level 3 work is a sprint where you contributed nothing assessable.
It still has to work. Not being assessed is not the same as not mattering. If your evaluated feature depends on it and it is broken, the evaluated feature is broken.
You are still responsible for it. It is in your repository and running in your project. If it leaks a key, mishandles data, or does something you cannot explain, that is yours to answer for. Do not ship what you have not read.

Where the dishonesty actually lies. Using AI on declared support work is not dishonest, no matter how much of it AI wrote. Three things are: declaring something as support when a rubric line does cover it; presenting AI-written support code as your own work, in your reflection, your video, or a conversation with me; and not declaring it at all. The first is the one to be careful about, because it is the one you might do by accident. If you are not sure whether something falls inside a rubric line, ask before you build it, not after it is graded. Asking is free and I will answer the same day.

Level 3 applies to Sprints and the Project only. Homework, quizzes, reading checks, and exit tickets have no unassessed parts; the whole artifact is the thing being measured, so there is nothing to declare. It is also narrower than the list in the previous section: seed data, fixtures, sample content, boilerplate config, and formatting need no declaration at all. Level 3 is for the parts big enough that someone reading your repository would otherwise reasonably assume you wrote them.

Disclosing what you used

Where it goes depends on what you are handing in. For anything submitted from a team repository, which is the sprints and the Project, add ai-disclosure/<your-name>.md, lowercase kebab case, for example ai-disclosure/tim-richards.md. One file per person, you write your own, and nobody has to merge with anybody. For anything you submit as your own archive, which is Homework, put one AI-DISCLOSURE.md at the root of the zip. Either way: one entry per thing you used AI for.

Level	What to write
Level 1	One sentence: what you asked about. No transcript.
Level 2	A few sentences: what you asked, what it said, what you changed and why. Include the exchange if you have it. If the tool does not produce a transcript, describe what it looked at.
Level 3	What the part is, where it lives in the repository, what job it does, why no rubric line covers it, and what the AI did. No transcript needed. Declare it before the work is graded, not after.

That is the whole requirement. Level 1 is deliberately cheap, because asking a general question is a normal part of learning and making you write a report about it would just stop you from disclosing it.

On a team repository, write your own section, covering your own commits. You are not responsible for disclosing what a teammate did, and you will not be penalized for a teammate’s omission that you could not reasonably have known about. Talk to each other when you merge.

Write it as you go and submit it with your work. On a team repository the file accumulates, it is not rewritten. It lives there all term, so put a heading for each sprint and write underneath it rather than replacing what is already there. Earlier sprints stay as a record; when a sprint is graded, only that sprint’s section is read.

You may be asked to explain your own work

Any week, in lecture, you may be asked to walk through a specific piece of something you submitted: what it does, why you wrote it that way, what you would have done instead.

This is low stakes. It is not a test and it is not an accusation. It is folded into that assignment’s existing grade and there is no separate studying for it, because the point is simply whether the work is yours to explain. If you did it, you will be fine.

You will not know in advance which piece. That is the whole design, and it is why the policy above can stay short: being able to explain your own work is the thing that actually matters, and it is much easier to check than anything else.

If a live conversation is a barrier for you, ask and we will find another format.

Facts are yours

This one applies at every level, including Level 0.

Any claim of fact in your work is yours. If an AI told you how consistent hashing works, or what a trade-off costs, or gave you a source, and you did not check it, and it is wrong, that is your error.

This matters more than it sounds. When AI writes wrong code, the compiler or the test suite usually tells you within seconds. Nothing tells you when it writes wrong prose. A confident, incorrect sentence in a README, a reflection, a poster, or a video script will pass every automated check this course has and land in your grade. Check what you repeat.

Accommodations, and writing in another language

Accommodations arranged through Disability Services override every level above. You do not need to make a case to me, and you do not need to disclose accommodated use in your disclosure file. It is not a disclosure event and it will never come up in any review of your work. If the explain-your-work conversation is a barrier, tell me and we will use a different format.

If English is not your first language, help with grammar and phrasing is fine on the reflections, discussions, README prose, and the individual reflection. Those exist to assess your thinking and your account of your own work, not your command of English prose. The substance has to be yours; the polish does not have to be.

If something does not add up

If your disclosure and your work do not seem to match, the first thing that happens is that I ask you about it. That is a conversation, not an accusation, and nothing is decided before it. Most of the time the answer is that the policy was unclear or something got left out, and we fix it and move on.

Only two things escalate past that: a disclosure that actively contradicts your work, or refusing to engage with the question at all.

And if you realize you went over the line, tell me before I ask. If you disclose it yourself, honestly and unprompted, we handle it as an academic matter for that piece of work, which may mean reduced credit or redoing it. It does not become an academic honesty referral. I would much rather you tell me.

How I use AI in this course

AI tools were used in building some of this course’s materials, alongside my own writing, editing, and review. I direct that work, I check it, and I am accountable for what it produces. Where a tool gets something wrong, that is my error and not the tool’s.

I mention it because I am asking you to disclose your own use, and a rule that runs in only one direction is not one anyone should respect. The reason it is not a double standard is narrow and specific: your submission is an instrument for measuring what you can do, and my materials are not. Nobody is trying to determine, from a syllabus, whether I can write a syllabus unaided.

What I owe you in exchange is a straight answer. Ask me, about anything in this course, how I checked that a given claim was true, and you will get one. If something here is wrong, I want to hear about it.

Disability Accommodation Statement

Reasonable accommodations are available; the sooner you register, the sooner they apply.

The following statement is required by the University and is reproduced verbatim. The University of Massachusetts Amherst is committed to providing an equal educational opportunity for all students. If you have a documented physical, psychological, or learning disability on file with Disability Services (DS), you may be eligible for reasonable academic accommodations to help you succeed in this course. If you have a documented disability that requires an accommodation, please notify me within the first two weeks of the semester so that we may make appropriate arrangements. For more information, consult the Disability Services website.

Disability Services is located at 161 Whitmore Administration Building and can be reached at (413) 545-0892.

Diversity, Equity, and Inclusion

A learning environment that works only when everyone in it is respected.

The Manning College of Information and Computer Sciences and this course are committed to a learning environment in which every student is welcomed and respected regardless of race, ethnicity, national origin, gender identity or expression, sexual orientation, disability, age, religion, socioeconomic background, or veteran status. Computing is built by teams, and the best computing is built by teams whose members bring different experiences to the problem. The Computing for the Common Good framing of this course rests on that premise: the systems you build are meant to serve real communities, which requires taking seriously perspectives other than your own. I expect every interaction in this course, in your teams, in your reflections, and in any communication with the staff, to be conducted with that respect. If anything in this course, including its examples, its assignments, or the conduct of a classmate, makes you feel excluded or unwelcome, please send me a Canvas Inbox message so that I can address it.

Title IX Statement

A safe learning environment, and the resources that protect it.

The following statement is required by the University and is reproduced verbatim. In accordance with Title IX of the Education Amendments of 1972 that prohibits gender-based discrimination in educational settings that receive federal funds, the University of Massachusetts Amherst is committed to providing a safe learning environment for all students, free from all forms of discrimination, including sexual assault, sexual harassment, domestic violence, dating violence, stalking, and retaliation. This includes interactions in person or online through digital platforms and social media. Title IX also protects against discrimination on the basis of pregnancy, childbirth, false pregnancy, miscarriage, abortion, or related conditions, including recovery. There are resources here on campus to support you. A summary of the available Title IX resources, both confidential and non-confidential, can be found at the following link: https://www.umass.edu/titleix/resources.

Chosen Names and Pronouns

You tell us who you are, and we use it.

I want to address you by the name and pronouns you use. If your chosen name or pronouns differ from what appears on the official roster, please send me a Canvas Inbox message at the start of the term, and I will use them in all communication and feedback. UMass Amherst allows students to designate a chosen name and a pronoun in SPIRE, which then propagates to Canvas and class rosters, and I encourage you to set these if you have not already. If I ever get your name or pronouns wrong, a quick, private Canvas Inbox message is welcome and I will fix it.

Student Support Resources

The course is hard by design; you do not have to navigate it alone.

Help with the course material comes first from the course staff, through a Canvas Inbox message addressed to all of us, and from the CICS supplemental instruction and tutoring resources offered through the Manning College advising office, which you can find on the CICS undergraduate advising pages. Beyond the course, the University offers support for the rest of your life as a student. The Center for Counseling and Psychological Health (CCPH) provides confidential mental health support and can be reached at (413) 545-2337, with a counselor available at that number at any hour. The Dean of Students Office helps students navigate personal emergencies, illness, and other circumstances that disrupt coursework, and can advocate on your behalf with instructors. The Writing Center offers free help with written communication, useful for the project poster and your reflections. The W.E.B. Du Bois Library provides research and technical resources, and the University offers food, housing, and financial assistance for students facing insecurity through the Dean of Students Office. If you are struggling for any reason, academic or otherwise, reach out early, to me through the Canvas Inbox or to any of these offices directly. Asking for help in time is a strength, and it is what these resources exist for.