Tutorial 1: Deployment, Scaling, and Observability
Unit 7 · Distributed and cloud web systems
Objectives
Identify stateless service properties.
Use logs, metrics, and traces to investigate behavior.
Reason about scaling and failure boundaries.
A stateless web process does not require a particular server instance to remember a user's session. Externalize session and durable data so instances can be added or replaced. Configuration belongs outside the image or source code, and secrets must not be committed.
Logs describe events, metrics summarize behavior over time, and traces connect work across services. Health checks should distinguish “process is alive” from “application is ready to receive traffic.”
Exercises
Choose three metrics for an API and define alert thresholds.
Explain how two service instances share sessions safely.
Design a readiness check that verifies required dependencies.
Self-check
Why externalize session state?
What is the difference between liveness and readiness?
What does a trace add to a log?
Self-Check Quiz
1. What makes a service easier to scale horizontally?
AnswerStateless request handling and externalized shared state allow requests to reach any healthy instance.
2. What should not be stored in source control?
AnswerSecrets such as passwords, private keys, and production tokens.
Homework
Write a deployment checklist for a web API.
Define logs, metrics, and traces for one user request.
Describe graceful behavior when the database is unavailable.
Sample answerA checklist includes configuration validation, secret injection, migrations, health checks, rollback, and monitoring. A request trace links gateway, application, and database spans. Database failure should produce a bounded timeout, a useful 503 response, structured logs, and no leaked credentials.