Exams and quizzes

Both exams are individual, written, scenario-based system-design assessments. They test whether students can apply concepts demonstrated in lectures to an unfamiliar but feasible backend scenario. No live programming, code repair, terminal work or container deployment is required in either exam. Questions use short business requirements, architecture constraints and failure traces. Student responses use diagrams, sequences, technical decisions and concise reasoning.

Exam logistics and expected answer artifacts

• Midterm: 20 marks, scheduled after Week 6; coverage is Weeks 1-6, including Lectures 1-3 and the concepts developed in Assignments 1-3: microservices, Docker, Compose, NGINX, PostgreSQL, RabbitMQ and failure handling.
• Final: 25 marks, scheduled after Week 12; cumulative coverage is Weeks 1-12, including every lecture and assignment, from API/container design to messaging, Saga, leader election, replication and recovery.
• Answers may include component/container diagrams, request/event sequence diagrams, state-transition tables, timeout/ACK choices and a failure-recovery narrative.
• Use a new system scenario or changed constraints, not simply reproduce lecture slides or the submitted food-delivery application.
• The examiner supplies assumptions about expected traffic, failure modes, storage and available infrastructure; students clearly identify any additional assumptions.

Midterm blueprint - 20 marks

Design question	Marks	Relevant lecture topics
Q1. Scale and route a service	8	Weeks 1-4: API, Docker, NGINX, Compose and shared persistence
Q2. Design an asynchronous workflow	8	Weeks 5-6: RabbitMQ, event contracts, consumer ACKs and crash recovery
Q3. Defend design choices	4	Weeks 1-6: coupling, latency, partial failure and trade-offs
TOTAL	20	Written system-design questions only

Illustrative midterm scenario (not a fixed exam paper)

Scenario: A ticket-booking application runs two Booking API replicas behind NGINX. Clients occasionally see missing bookings when they hit another replica. After confirmation, a background email worker crashes; some messages are delivered again after restart. The booking API must return quickly without losing confirmed bookings.

1. Q1 - 8 marks: Draw the proposed API/gateway/container topology (3); specify state ownership and shared persistence (2); explain request routing, timeouts and backend unavailability (3).
2. Q2 - 8 marks: Draw a booking-confirmation event sequence (3); define publish/consumer ACK and crash-recovery behavior (3); prevent duplicate notification side effects (2).
3. Q3 - 4 marks: Compare synchronous versus asynchronous notification delivery (2); state two availability or reliability trade-offs in the proposed design (2). Marking principle: award credit for a coherent design and justified failure behavior, not a specific product name or a diagram that merely lists components.

Final examination blueprint - 25 marks

Design question	Marks	Relevant lecture topics
Q1. Consistent multi-service checkout	10	Weeks 1-8: gateway, persistence, messaging, idempotency, Saga
Q2. Coordinator failover and exclusivity	9	Weeks 9-10: election, heartbeats, fencing, stale-leader protection
Q3. Replication and recovery	6	Weeks 11-12: primary-backup, replay, stale reads, recovery
TOTAL	25	Integrated written system design across Weeks 1-12

Illustrative final-exam case (not a fixed exam paper)

Scenario: A parcel-delivery backend has multiple public API replicas behind NGINX, asynchronous payment and dispatch workers, and three delivery coordinators. Customers sometimes repeat requests after timeouts; a stock-like capacity counter is updated concurrently. An old coordinator briefly reconnects after a new leader was elected, while one delivery-state replica has fallen behind.

1. Q1 - 10 marks: Show request/event flow and service responsibilities (3); design a Saga with at least one compensation path (3); explain idempotency and concurrency control for repeated requests and capacity updates (4).
2. Q2 - 9 marks: Propose a coordinator election/failure-detection design with assumptions (3); show how a persisted epoch/fencing token rejects stale leaders (3); analyze an overlapping-leader failure trace and limits of the method (3).
3. Q3 - 6 marks: Draw the replica topology and write path (2); explain gap detection, replay and convergence after reconnect (2); define when writes are acknowledged and which reads may be stale (2).

What strong exam answers must demonstrate

• Correct interfaces: distinguish client gateway, service-to-service calls, message broker, database and replica roles.
• Failure reasoning: name what happens after a timeout, redelivery, stale leader, concurrent write or replica outage.
• Explicit guarantees: avoid claims such as exactly-once message delivery, automatic zero-data-loss failover or NGINX solving application consistency.
• Trade-offs: note cost, complexity, latency and availability implications without requiring a specific vendor.

Scheduled written quizzes - 15 marks

Quiz	Marks	Coverage / timing
Quiz 1 (Week 4)	5	Weeks 1-4: Lecture/Assignment 1 and 2
Quiz 2 (Week 8)	5	Weeks 5-8: Lecture/Assignment 3 and 4
Quiz 3 (Week 12)	5	Weeks 9-12: Lecture/Assignment 5 and 6
TOTAL	15	Each quiz: five short-answer questions x 1 mark

Optional individual extension - no extra maximum marks

After Week 8, an individual student may request approval for an outbox recovery dashboard, trace viewer, automated fault-injection runner, or replica-consistency test harness. It may restore up to 3 previously lost marks within the 40-mark lab component; the lab maximum remains 40/40. It is not an examination alternative and is not required for a full course score.

Exam administration

Provide a common fact sheet defining network, failure and data assumptions. Announce allowed aids, writing time and diagram conventions before the exam. Grade for technical correctness, failure analysis and justified decisions; permit alternative designs that meet the stated requirements. Midterm and final take place in separate exam windows, preserving the 12 lecture/evaluation classes.

Quiz format and sample questions

There are three individual quizzes, administered immediately after the evaluation activity in Weeks 4, 8 and 12. Each quiz is a short written-answer quiz with exactly five questions; each question carries 1 mark. Time: 15-20 minutes. Students may answer in one or two sentences, label a small architecture diagram, or give a concise reasoning step. Total: 3 x (5 x 1) = 15 marks. The prompts below are illustrative, not mandatory final papers.

Quiz 1 - Week 4 | Coverage: Weeks 1-4 | 5 marks

1. Q1 (1): Name one failure mode that can affect a remote REST call even when both services are correctly implemented.
2. Q2 (1): In one sentence, distinguish a Docker image from a running container.
3. Q3 (1): How can the Order Service reach the Restaurant Service by service name inside a Compose network?
4. Q4 (1): Why can two load-balanced API replicas return different results if each stores orders only in its own memory?
5. Q5 (1): Name one persistence mechanism that prevents order records from disappearing when an API container restarts.

Quiz 2 - Week 8 | Coverage: Weeks 5-8 | 5 marks

1. Q1 (1): What is the difference between a RabbitMQ publisher confirm and a consumer ACK?
2. Q2 (1): A worker crashes after updating its database but before ACKing the message. What may happen to that message?
3. Q3 (1): What problem does an idempotency key prevent during repeated payment requests?
4. Q4 (1): Name one SQL-level technique for preventing two customers from reserving the final item simultaneously.
5. Q5 (1): In an order-processing Saga, what should happen to a reserved item when the payment is rejected?

Quiz 3 - Week 12 | Coverage: Weeks 9-12 | 5 marks

1. Q1 (1): What evidence might trigger a new coordinator election in a heartbeat-based design?
2. Q2 (1): What is the purpose of a fencing token or monotonically increasing leadership epoch?
3. Q3 (1): Why is leader election by itself insufficient to prevent a stale leader from writing shared state?
4. Q4 (1): In primary-backup replication, where are accepted writes first ordered?
5. Q5 (1): How can a disconnected replica catch up when it missed several sequenced state changes?

Quiz administration and marking

• Every question is worth exactly 1 mark. Award the mark for the key concept or technically valid short explanation; avoid requiring unnecessary memorized wording.
• Use a short-answer marking key stating one expected idea per question. Keep alternate valid answers acceptable when they satisfy the scenario.
• Question papers should be different from (but equivalent in difficulty to) the illustrative sample questions. No group submissions or shared answers.
• Quiz 1 occurs in the Assignment 2 evaluation class; Quiz 2 in Assignment 4; Quiz 3 in Assignment 6. Reserve 15-20 minutes so the 12-week lab sequence is preserved.