In 01-06 we opened up a Python monolith with a PostgreSQL database, a Tuesday-and-Thursday deployment and five symptoms pushing it to change, and we drew a target architecture with a table that pointed each component at a future lesson. Thirty-eight lessons later, every one of those boxes has been built: gRPC and Kafka, sagas and replicas, Cassandra and Redis, Spark and Flink, Keycloak and Vault, Prometheus and Kubernetes, MQTT and WebSockets, Terraform and Lambda, the CDN and the van's SQLite queue. This last lesson adds no new piece: it assembles the ones we have. First the complete architecture in a single diagram and the table from 01-06 closed off; then the journey of one of Anna's orders from her browser to the invoice in S3, with everything it leaves in its wake in traces, metrics and audit records; then the six architecture decisions as ADRs, with their rejected alternatives and their consequences; the five symptoms of 01-06 with their resolution; the assessment of the platform against the course's own criteria (fallacies, consistency per piece of data, SLOs, RPO/RTO, security controls); what is left out; the project the student can build on their laptop with verifiable milestones; and a guide for going deeper. The exercises are integration exercises: bringing in a new domain, analysing an incident end to end and trimming the architecture down for three people. The conclusion closes the course.

1. The final architecture of Kilometre Zero
2. The table from 01-06, closed
3. The journey of one of Anna's orders end to end
4. What the order leaves in its wake: traces, metrics and audit
5. The architecture decisions as ADRs
6. The five symptoms of 01-06, revisited
7. Assessment against the course's criteria
8. What is left out and next steps
9. The project: a reduced Kilometre Zero in docker-compose
10. Study guide
11. Common Mistakes and Tips
12. Exercises
13. Conclusion

The diagram has one piece that until now was only promised: the courier app BFF, announced in 06-05 and placed in 08-01. It is a small service, owned by the delivery team, behind Kong, that composes the app's home screen (the day's route from delivery, the status of that route's orders from orders, product names and photos from catalog) into a single response, with parallel calls, short timeouts and graceful degradation (if catalog does not answer, the route is shown without photos). It has no database: it is API composition (08-01, section 5), justified because the app makes few calls, the data is small and it needs freshness.

The table in 01-06 was a promise: each component, and the lesson where it would be built. This is the same table, closed, with what was finally built and the file or name that materialises it in km0/.

Anna, in Valencia, buys two aged-cheese from Montblanc Dairy and one crianza-wine from Roble Alto Winery. The order is P-2026-000125. This is the complete journey, with the lesson in which each step was built.

Five observations about the diagram that sum up the course:

1. Only two synchronous calls between services (steps 9 and 12), both with a timeout, a circuit breaker and mTLS, and both because their response governs the next decision (08-01). Everything else is events.
2. No transaction crosses services. The order is created in Cassandra, the reservation in RDS and the charge at the gateway as local transactions; the saga chains and compensates them (03-05); the outbox guarantees that events go out if and only if the local transaction commits (02-05).
3. Idempotency appears four times: Anna's Idempotency-Key at Kong/orders (a double click does not create two orders), the reservation_id in inventory, the charge-<order> key towards the gateway, and the event_id in every consumer. A retry at any point is safe.
4. Anna receives her response at step 17, before the catalogue view, the delivery assignment or the invoice exist. What she sees afterwards (the van's position, the invoice in her account area) arrives by asynchronous paths with seconds of delay, which is the normal state (08-01).
5. The edge and the gateway do their job before anything reaches the services: the JWT is verified three times (Worker, Kong, service), rate limiting protects orders, and the product listing never even reached the region.

An order does not only produce state; it produces evidence. What remains after P-2026-000125:

The proof that observability has been done well is that with the order_id everything can be reconstructed: from the logs to the trace_id, from the trace to each service and its latency, from the metric to whether that order was one of those that broke the SLO, from the event in the lake to what analytics computed, from the audit record to who did it. That is what exercise 2 puts to the test.

In 08-01 the full ADR-001 was written. These are Kilometre Zero's six structural decisions in summary format: each with the alternative that was rejected and the negative consequence that was accepted, which is the part that in a year's time will tell whether it is still valid.

Every ADR lives in km0/docs/adr/ADR-00N-*.md, in the full format from 08-01. Note that three of the six decisions (002, 003, 006) explicitly reject a "more modern" or "more managed" option: the architecture is not the sum of the best technologies but of the decisions that answer a symptom at a known cost.

A good course leaves criteria, not just techniques. These are the five with which Kilometre Zero assesses itself, and with which the student can assess any other platform.

The lesson of this table is that "strong" appears twice and "eventual" six times: strong consistency is paid for and reserved for what truly needs it.

No architecture is ever finished; this one has five open fronts, each with the course module that provides the tools to tackle it:

1. Active-active multi-region. Today there is a pilot light (07-03, 08-03): the secondary region takes 1-2 hours to serve. Moving to active-active would require deciding the write model per piece of data: km0_orders in multi-DC Cassandra (LOCAL_QUORUM per region, 04-04) is natural; stock (inventory) is not, and would force partitioning authority by market (Girona and Lleida write in eu-west-1, Valencia in eu-central-1) with the multi-leader model of 03-04 for the markets split across regions. It is a months-long project and the pending ADR-007.
2. Full event sourcing. Today events are notifications of state changes that are stored separately (and forever in the lake). Event sourcing would make the events the source of truth for orders: state is rebuilt by replaying order.created, payment.confirmed, ... You gain perfect auditability and the ability to rebuild any view; you pay with snapshots, versioning of historical events and queries that always go through a projection. CQRS (08-01) has already prepared the ground.
3. Data mesh. analytics is today a central team that consumes everything. As the domains grow, each team would start publishing its data as a product (with a schema, quality, an SLA and an owner) and analytics would become a platform. It is Conway's law (08-01) applied to data.
4. The internal platform as a product. The platform team from 08-01 exists; what is missing is treating it as a product: a portal where a team creates a new service with its Deployment, its dashboards, its alerts, its pipeline and its template ADR in minutes (exercise 1 puts this to the test).
5. Cost as a design constraint. FinOps (08-03) measures; the next step is for cost to enter architecture decisions the way latency does: euros per order as an SLO, a quarterly review of managed versus self-run services, and automatic shutdown of anything not serving traffic.

The course has shown code in every lesson; the project proposes building a reduced, working version on your laptop, with what fits in docker-compose and no cloud: catalog, orders, inventory, Kafka, PostgreSQL, Redis and Prometheus. payments is simulated, delivery and analytics are optional, and the rest of the platform (Keycloak, Kubernetes, Terraform, Lambda, CDN) is outside the minimum scope. What matters is not the size but that every milestone is verifiable with a command.

Every milestone should end with a short ADR if a decision is taken (for example, "PostgreSQL instead of Cassandra for orders in the reduced version: context, consequences") and with the tests that verify it in tests/. The result is a repository you can show and talk about in an interview with the same precision with which this course has talked about Kilometre Zero.

The course has been a map; these are the territories to explore next. Works and papers are cited by title and author, without links: all of them are easy to find by name.

Reference books

• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017). The book that most resembles Modules 2, 3 and 4 of this course, in far greater depth: replication, partitioning, transactions, consensus, batch and stream processing. It is the natural next read.
• Andrew S. Tanenbaum and Maarten van Steen, Distributed Systems (3rd ed., available free of charge from the authors). The classic academic text: models, communication, synchronisation, consistency and fault tolerance with formal rigour. It complements Modules 1 and 3.
• Sam Newman, Building Microservices (2nd ed., O'Reilly, 2021) and Monolith to Microservices (2019). Everything in 08-01 in detail: boundaries, migration, testing, organisation.
• Betsy Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems and The Site Reliability Workbook. The origin of the SLOs, error budgets, postmortems and on-call of Module 7. Available free online from Google.
• Eric Evans, Domain-Driven Design (2003), and Vaughn Vernon, Implementing Domain-Driven Design (2013), to go deeper into the bounded contexts of 08-01.
• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns (2003): the catalogue of messaging patterns from which 02-04 and 02-05 took their names.
• Neal Ford, Mark Richards et al., Software Architecture: The Hard Parts (2021): trade-offs of decomposition, distributed data and sagas, in the same ADR spirit.

Foundational papers (all findable by title)

• Leslie Lamport, "Time, Clocks, and the Ordering of Events in a Distributed System" (1978): the basis of 01-05. And "The Part-Time Parliament" (1998) and "Paxos Made Simple" (2001) for consensus.
• Diego Ongaro and John Ousterhout, "In Search of an Understandable Consensus Algorithm" (Raft, 2014): what etcd and Kafka KRaft implement (03-03).
• Giuseppe DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (2007): consistent hashing, quorums, vector clocks and the choice of availability that Cassandra inherits (04-01, 04-04).
• Jeffrey Dean and Sanjay Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters" (2004), and Sanjay Ghemawat et al., "The Google File System" (2003): 05-02 and 04-02.
• James C. Corbett et al., "Spanner: Google's Globally-Distributed Database" (2012): strong consistency at global scale with bounded clocks (TrueTime), the counterpoint to Dynamo.
• Jay Kreps, Neha Narkhede and Jun Rao, "Kafka: a Distributed Messaging System for Log Processing" (2011), and Jay Kreps's essay "The Log: What every software engineer should know about real-time data's unifying abstraction" (2013): the idea of the log as the backbone (ADR-004).
• Hector Garcia-Molina and Kenneth Salem, "Sagas" (1987): the original paper behind 03-05.
• Seth Gilbert and Nancy Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (2002), and Daniel Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC, 2012): 03-02.
• Marc Shapiro et al., "Conflict-free Replicated Data Types" (2011): the CRDTs of 03-01 and 08-04.
• Peter Deutsch and James Gosling, the "Fallacies of Distributed Computing", and Peter Bailis et al., "Highly Available Transactions: Virtues and Limitations" (2013), to continue with the fallacies and isolation models.
• Tyler Akidau et al., "The Dataflow Model" (2015): event time, watermarks and windows from 05-04.

Practice

• Jepsen (Kyle Kingsbury): public analyses of how real databases fail under partitions; the best school of scepticism about advertised guarantees.
• Michael Nygard's Release It! (2nd ed., 2018), for the stability patterns of 07-04 told through real incidents.
• Build the project from section 9 and then break it with the experiments from 07-06.

• Presenting the architecture as a diagram without decisions. The diagram in section 1 is worth little without the ADRs in section 5; what you learn from an architecture is its rejected alternatives and its accepted consequences.
• Assessing by technologies rather than by criteria. "It uses Kafka and Kubernetes" says nothing about whether it is well designed. The tables in section 7 (fallacies, consistency per piece of data, SLOs, RPO/RTO, who can do what) do.
• Starting the project with the infrastructure. Kubernetes, mesh and Terraform with no service to deploy is the mistake of "choosing technologies before problems" from 01-06. The project starts at M1 with three services and docker-compose.
• Believing the platform is finished. Section 8 lists five open fronts; an architecture without a backlog is one nobody is looking at.
• Tip: in any new system, start by writing down the symptoms (01-06), the consistency-per-data table (03-01) and the SLOs (07-01) before drawing boxes. They are the three pages that produce the most correct decisions.
• Tip: keep this course as a reference by lesson: when in a year's time you have to decide between orchestration and choreography, or how much TTL to put on a CDN, the corresponding lesson has the table.

In 08-01 it was decided that reviews are a bounded context of their own with event-based communication. Now design it end to end applying the whole course: (a) the contract of events it consumes and produces (with the envelope from 02-04) and the data model with its consistency model (03-01) and its storage (Module 4); (b) the public API at Kong with authentication and authorization (who may review what; 06-01, 06-05) and how the average reaches the listing cached by the CDN (08-04); (c) SLO, metrics and alerts (07-01), and what traces and audit records a review leaves behind; (d) deployment (07-05), RPO/RTO (07-03) and what would have to be added to main.tf (08-03); (e) ADR-007 in summary format (decision, rejected alternative, consequence).

Saturday 19 September, 18:42, Artisan Cheese Week. The alert "orders SLO: error budget burn ×14 in 5 min" fires. Available data:

• Prometheus: rate(km0_orders_total{status="rejected_stock"}[5m]) goes from 0.3/s to 9/s at 18:40; the p99 latency of POST /orders drops from 420 ms to 95 ms; km0_grpc_client_duration_seconds{method="ReserveStock"} p99 = 8 ms; km0_circuit_state{dependency="inventory"} = 0; lag of the catalog-projection group = 0.
• inventory logs (Loki): from 18:39:50, hundreds of lines {"level":"warning","msg":"InsufficientStock","product":"aged-cheese","market":"girona","available":0,"requested":2,"request_id":...}.
• catalog logs: {"level":"info","msg":"view updated","product":"aged-cheese","market":"girona","applied":true} at 18:39:48, and none after that for that product.
• Traces: the rejected orders have spans kong → orders → inventory.ReserveStock (InsufficientStock) of 90 ms; none reaches payments.
• products_view in catalog: aged-cheese / girona: available = true, approx_units = 0, stock_version = 1758300000123.
• Audit: at 18:39:45, {"sub":"mhill","action":"stock.adjust","resource":"aged-cheese/girona","from":140,"to":0,"source":"producer-dashboard"}.

(a) Reconstruct the complete causal chain. (b) Is it a platform incident, a product incident or an operations incident? Which part of the behaviour is correct and which is a defect? (c) Locate the exact defect in the code from 08-01 (stock_projection.py or products_view.sql) and fix it. (d) Write the three postmortem actions (07-03) and say which signal would have detected the problem before the SLO did.

A three-person startup wants to launch a marketplace like Kilometre Zero in a single market, with 20 producers, 300 orders a day and 6 couriers. They have three months and cannot operate Kubernetes or Kafka. Using the "when not to use microservices" table from 08-01 and the selective lock-in of 08-03, design the minimum architecture: (a) what stays as a modular monolith and with what internal structure; (b) which three Kilometre Zero decisions you would keep intact because they are cheap and prevent irreversible mistakes; (c) how you would handle real-time tracking and photos without Kafka, MQTT or Lambda; (d) which measurable signals would indicate that the time has come to extract the first service, and which one it would be.

Exercise 1.

(a) It consumes order.delivered (published by delivery on orders.events with the standard envelope; data: {order_id, customer, lines: [{product, producer}], delivered_ms}) to know what can be reviewed. It produces on a new topic reviews.events (3 partitions, key = product, so that a product's reviews reach the projection in order): review.created {review_id, customer, order_id, product, producer, points, comment, timestamp_ms} and review.replied {review_id, producer, reply, timestamp_ms}. Model: tables reviewable (customer, order_id, product, delivered_ms, reviewed bool) and reviews (id, customer, product, producer, points, comment, reply, created_at) in its own PostgreSQL database km0_reviews (a small RDS, without Multi-AZ at first): low volume (one per delivered line), relational queries (by product, by producer, awaiting reply), and the rule "one review per line" requires a UNIQUE (customer, order_id, product) constraint with local strong consistency. The average on the listing is eventual (a projection in catalog), and the producer dashboard reads its own database with strong consistency.

(b) Routes at Kong: POST /api/v1/reviews (role customer), GET /api/v1/products/{slug}/reviews (public, cacheable for 60 s), POST /api/v1/reviews/{id}/reply (role producer), GET /api/v1/producers/me/reviews?pending=true (role producer). Authorization in the service: on creation, claims.sub must have an unreviewed row in reviewable for that order and product (ABAC on its own data, without calling orders); on reply, claims.producer_id must match reviews.producer. Specific rate limiting (5 reviews/minute per consumer) against abuse. The average reaches the listing because catalog consumes review.created and maintains points_sum and review_count in products_view (idempotent by event_id); the listing stays public, max-age=60 per market, and the average changes with up to a minute's delay at the CDN, which is acceptable. The three latest comments are served on the public reviews route (cacheable, with no personal data beyond the first name, which the customer consented to).

(c) SLO: 99.5% availability and p99 < 300 ms for creation (it is not on the purchase path: a looser SLO than orders). Metrics: km0_reviews_total{result}, latency per route, lag of the order.delivered consumer and of the catalog consumer on reviews.events. Alerts: error budget burn, lag > 5 min (a delivery that cannot be reviewed), and an anomalous rate of unauthorized (abuse). Trace: kong → reviews POST → postgres, linked to the catalog consumer by the event_id. Audit: reviews.create and reviews.reply on audit.events (producers' replies are public content, and moderation needs to know who wrote what).

(d) k8s/reviews-deployment.yaml copying the orders template (2 replicas, probes, resources, topologySpreadConstraints, HPA by CPU, a NetworkPolicy that only allows ingress from Kong and egress to its RDS and to Kafka, serviceAccountName with IRSA and no S3 permissions). RPO: minutes (RDS backups and PITR; losing reviews is tolerable but annoying); RTO: 1 hour (it does not block sales). In main.tf: aws_db_instance.reviews (db.t4g.small, no multi_az), its security group (5432 only from EKS), an IRSA module with no S3 policies, and the reviews.events topic managed with the kafka provider or created by the pipeline.

(e) ADR-007: "reviews as its own bounded context with PostgreSQL and communication exclusively through events". Rejected alternative: inside catalog (it would couple moderation to the catalogue's deployments during campaigns and mix two languages: "published product" and "review"). Accepted consequence: the listing shows the average with up to a minute's delay; one more component with a database, a dashboard and on-call (owned by the catalogue and producers team); if delivery stops publishing order.delivered, nobody can review until the lag recovers (alert).

Exercise 2.

(a) Causal chain: at 18:39:45, Martha Hill adjusts the stock of aged-cheese in Girona from 140 to 0 from her dashboard (probably a data-entry mistake, or a genuine withdrawal of the product). inventory applies the adjustment and publishes stock.updated {available: 0}. At 18:39:48, catalog receives the event and the projection applies it (applied: true) → approx_units = 0. But available stays true. From 18:39:50, customers who see the listing (with available = true) add aged-cheese to their basket and confirm; orders starts the saga, inventory answers InsufficientStock in 8 ms, the saga compensates and the order ends up rejected_stock. The p99 latency drops (rejected orders never go through the gateway), the rejection rate rises ×30 and the error budget is consumed because rejected_stock counts as a failure of the orders SLO.

(b) It is a mixed incident. The saga, the circuit and the compensation work correctly: no order was charged without stock, no reservation was left hanging. Martha's adjustment is a legitimate business action (and the audit records it precisely). The defect lies in the platform: the catalogue listing keeps saying "available" with 0 units, steering hundreds of customers into a certain rejection. It is a defect in the CQRS projection, not in eventual consistency: the delay was 3 seconds, which is acceptable; the problem is that the projected data is incorrect permanently.

(c) In stock_projection.py, apply computes avail = d["available"] >= AVAILABLE_THRESHOLD with AVAILABLE_THRESHOLD = 1: with available = 0, avail = False, and the UPDATE should have set available = FALSE... unless the stock_version < %(v)s condition failed. But the log says applied: true, so the UPDATE did affect the row. So the defect is not there; look at products_view.sql: available BOOLEAN NOT NULL DEFAULT FALSE and approx_units are updated together in the same UPDATE. The row shows approx_units = 0 and available = true, which is only possible if another write path set available = true afterwards: the product publication path used by the producer (catalog creates/updates the row when the producer edits the listing and, according to 08-01, "the row is created by catalog when the producer publishes the product"). Martha edited the listing (perhaps the same adjustment from the dashboard touches both product and stock), and the publication UPSERT overwrites available with its default value or with the value the listing had in the form, without respecting stock_version. The defect is that two paths write the same column with different rules: the fix is for listing publication to never write available or approx_units (columns owned exclusively by the projection), that is, INSERT ... ON CONFLICT (slug, market) DO UPDATE SET name = EXCLUDED.name, price_cents = EXCLUDED.price_cents, producer = EXCLUDED.producer without touching the stock columns; and, as a safety net, a CHECK (NOT available OR approx_units >= 1) on the table that would make the incoherent write fail rather than let it through. It is the "data owner" principle of 08-01 applied inside a service, column by column.

(d) Blameless postmortem (07-03): 1. Fix the publication UPSERT and add the CHECK; an integration test (07-06) that publishes the listing after a stock.updated to 0 and verifies available = false. 2. Add a confirmation in the producer dashboard for stock adjustments that change more than 50% ("Set aged-cheese in Girona to 0 units? There were 140"), because the audit shows an improbable jump. 3. Separate stock rejections (a correct business outcome) from platform errors in the orders SLO, or create a specific "rejected_stock rate per product" alert with a low threshold, so that the symptom is attributed properly. The signal that would have caught it earlier: a coherence alert on the projection, count(products_view where available and approx_units = 0) > 0, evaluated every minute (a cheap query), or the Flink stock_alerts metric from 05-04 for aged-cheese in Girona, which fired at 18:39:50 towards inventory.alerts and which Martha received over SSE (08-02) but which nobody correlated with the rejections.

Exercise 3.

(a) A modular monolith in Python (FastAPI) with one managed PostgreSQL database (RDS or Cloud SQL with automatic backups and PITR, without Multi-AZ at first), deployed on a container PaaS (Cloud Run, App Runner, Fly.io, Render: 2 instances, autoscaling included, managed TLS). Internal structure: the six packages from 01-06 (catalog, orders, inventory, payments, delivery, analytics), each with its api.py as the only public module (08-01), PostgreSQL schemas separated per package (inventory.skus, orders.orders) and a lint rule (import-linter) that forbids importing another package's private modules and SQL queries across schemas. The order confirmation transaction is local (a single database): reservation, order and charge record in one transaction, with the gateway call outside it (charge first with an Idempotency-Key, then confirm in the transaction; if the confirmation fails, refund). A small managed Redis for the catalogue cache and the rate limiter. A single repository, one pipeline, docker-compose for development.

(b) Three cheap decisions that prevent irreversible mistakes: 1. The event envelope and an events table (outbox) from day one, even if the "bus" is the database itself and the consumer a process inside the monolith: when Kafka arrives, the producers already publish and the consumers are already idempotent; and the analytical lake can start by exporting that table to Parquet every night. 2. Idempotency in the write APIs (Idempotency-Key on create order, deterministic keys towards the gateway): it is what in 02-05 and 08-04 prevents duplicate charges and orders, it costs one table, and it cannot be added later without migrating clients. 3. Minimal observability with an SLO: JSON logs with request_id, RED metrics and a written SLO for create order; without this, there will be no data to decide when to extract anything (part d). And a free fourth one: ADRs from day one.

(c) Tracking: 6 couriers sending positions via HTTPS POST every 10 s to the monolith (60 requests/minute: nothing), stored in a delivery.positions table with 24 h retention (at this volume, PostgreSQL is more than enough), and customers using SSE or polling every 5 s against an endpoint that returns the order's last position (with Cache-Control: max-age=4 so that the PaaS or a CDN absorbs repeats). No MQTT or WebSockets: there is no volume to justify them, and SSE with automatic reconnection covers the experience. Photos: upload via presigned URL to S3/GCS (04-03, kept) and thumbnails generated in the monolith itself as a background task (a simple queue in PostgreSQL with SELECT ... FOR UPDATE SKIP LOCKED, processed by a worker in the same deployment), with a free or low-cost CDN in front of the bucket using immutable keys (08-04, kept because it is almost free and avoids egress).

(d) Signals for extracting the first service, measurable thanks to (b)-3: the p99 of create order degrades when catalogue traffic rises (contention on the same database or CPU: symptom 1); the team grows from 3 to 8-10 people and catalogue deployments break orders (symptom 3); read traffic exceeds what Redis plus a PostgreSQL read replica can absorb; or the gateway's latency starts to block connections (symptom 2). The first to go, as in 01-06, is catalog (reads only, no cross-cutting transactions, rollback with a route change) or, if the dominant symptom is the gateway, payments with its ACL. Never orders and inventory first: they are the ones that demand sagas, and sagas are only justified when the boundary already exists for another reason. The rule from 08-01 holds in reverse: three people with no symptoms is exactly the row of the table that says "modular monolith".

Kilometre Zero began as a Python monolith with one database and five symptoms, and ends as a platform that can be drawn in a diagram, walked through with an order, justified with six ADRs and assessed against the criteria the course itself has provided: the eight fallacies assumed false at specific points of the design, a consistency-per-data table where "strong" appears twice and "eventual" six times, SLOs and RPO/RTO per component, and a who-can-do-what table from Anna to the CDN Worker. Each of the five symptoms from 01-06 has its resolution and its way of being verified; each decision has its rejected alternative and its price; and what is left out is written down, with the module that provides the tools to tackle it. The proposed project reduces all of that to what fits on a laptop, with ten milestones that are checked with a command, and the study guide points to the books and papers where every idea in this course has its origin and its depth.

What the student can now do is not "use Kafka" or "deploy on Kubernetes", although that too. It is something more durable: faced with a system that has to be spread across several machines, they know to write down the symptoms first and not the technologies; to cut boundaries where the language changes meaning and not where there is a table; to choose for each piece of data the consistency model it needs and pay only for that; to give every call a timeout, every message an identifier and every consumer idempotency, because the network is going to fail; to replace the global transaction with a saga that compensates; to put data where its workload asks for it, from PostgreSQL to Cassandra, from Redis to S3, from the CDN to a van's SQLite queue; to separate what is computed in batches from what cannot wait; to authenticate and authorize at every boundary without trusting any; to measure with SLOs, observe with traces, recover with tested backups and rehearse failures before they happen; to describe infrastructure as code and cost as a metric; and to leave every decision written down with its context and its consequences, so that whoever comes next can change it knowingly.

That is what designing distributed architectures means: not piling up pieces, but knowing for each one what is gained, what is lost and why it was chosen. Kilometre Zero has been the pretext; the judgement is what the student takes away. Thank you for following the course this far, and good luck with the next system that has to be spread across several machines: you now know where to start.