We have reached the end. TechCorp has gone from a monolith with five measurable problems (01-05) to six services operated with SLOs, deployed eleven times a day and secured in layers; we have told the migration (08-01), written the complete system (08-02) and deployed and operated it (08-03). This last lesson adds nothing new to the system: it distills what was learned so you can take it to your own context. First, TechCorp's lessons organized by dimension, each in the most honest form possible ("what we did, what went wrong, what we would do differently"). Then, the catalog of antipatterns we have seen and how to recognize them in time. Next, a consolidated list of best practices with the lesson where each one is explained, what TechCorp would do in its phase 2 and by what criterion, and a guide for the learner: how to decide, where to start, how to practice with the course environment and what to read next. And the close: the module-by-module journey and Marta's and Luis's final words.

1. Lessons learned by dimension
2. Catalog of antipatterns and how to detect them
3. Consolidated list of best practices
4. What TechCorp would do in phase 2
5. Guide for the learner: applying the course to your context
6. Recommended reading and resources
7. Course wrap-up (in the conclusion)

Each table summarizes one dimension of the course. The "what we would do differently" column is the most useful one: it is what TechCorp would write in the project postmortem.

All of them have appeared in the course, almost all at TechCorp. The "how to detect it" column is a test you can apply to your system tomorrow.

Twenty-five points, grouped, with the reference lesson. Use it as an architecture review or new-service checklist.

Decision and design

1. Adopt microservices for measurable problems, not for fashion; build the four prerequisites on top of the monolith and modularize it first (01-04, 02-02, 08-01 phase 0).
2. Cut by business capabilities and bounded contexts; validate with event storming and the table × area matrix (02-02, 02-03).
3. One service = its data: its own database (or schema), opaque ids, no cross-service FKs, read replicas via events (02-04).
4. Replace the distributed transaction with a saga with an explicit state machine, compensations as events and a watchdog (02-05, 06-03 §9).
5. Extract in order of value/risk/dependencies with strangler fig behind a gateway and branch by abstraction with flags; never delete the old thing on cutover day (02-02, 08-01).

Communication 6. Contracts first (OpenAPI/AsyncAPI), RFC 7807 errors with code, 202 for asynchronous processes, ETag for polling (03-01). 7. Events with a standard envelope (eventId, type, version, occurredAt), topic exchange, one queue per consumer with deferred retry and DLQ (03-02, 06-03 §8). 8. Transactional outbox to publish; processOnce + business idempotency (UNIQUE) to consume; Idempotency-Key on POSTs (02-05 §7-8, 04-04, 08-02). 9. Thin gateway; composition in a BFF or a service; ACL at every boundary (03-04, 02-03). 10. Version: add without removing, /v2/ only for breaking changes, Deprecation/Sunset, event upcasting, HTTP and message pacts with can-i-deploy (03-06, 04-05, 05-03 §4).

Implementation 11. Service template + versioned technical library; business logic is not shared (04-01, 02-02 §6). 12. createApp without listen, dependency injection by parameter, layers pointing inward (04-02). 13. Configuration validated at startup, fail-fast, secrets outside the code and the image (04-03, 07-03 §7). 14. Pyramid: domain unit tests, component tests with doubles, integration with Testcontainers, contract with Pact, one E2E (04-05). 15. No external call inside a transaction; short transactions and idempotency-key lookup when in doubt (01-05, 08-02 §4).

Platform and deployment 16. Multi-stage images, non-root, tagged by sha and semver, scanned and signed; never latest (05-01, 07-04 §2). 17. Kustomize base + overlays per environment; Helm for third parties with versioned values; probes, securityContext, PDB, real requests (05-02, 06-04, 07-04). 18. GitOps: production changes by PR; Argo CD syncs; rollback = revert the commit (05-03 §6). 19. Progressive deployments per service (rolling, canary, blue-green) with expand/contract and event compatibility (05-04). 20. Reusable, versioned CI workflow; Luis's rule (05-03 §11).

Operations and security 21. Structured logs with redact, RED and business metrics with bounded labels, traces with context propagated over HTTP and through events (06-01, 06-02). 22. Timeouts always, retries only for transient errors with backoff, circuit breaker, bulkhead, DLQ with a runbook (06-03). 23. SLOs with an error budget, symptom and burn rate alerts, on-call with runbooks, blameless postmortems with actions (06-05). 24. Portable identity (OIDC/JWT) verified at the gateway and in every service; authorization by role, scope and owner; TLS everywhere; signed webhooks (07-01, 07-02). 25. Strict input validation, GDPR by design (minimization, retention, erasure), immutable audit log, secrets via operator, deny-all NetworkPolicies, minimal RBAC, and an honest to-do list (07-03, 07-04).

None of this is urgent; each item has a criterion that says when to tackle it. It is the difference between a roadmap and a wish list.

Deciding. Go back to the matrix from 01-04 and answer with data, not opinions:

Four or more "yes" with the prerequisites ready: extract incrementally, starting with the clearest reason. Fewer: modular monolith and a review in six months. And remember that the list in 01-04 has warning signs (a three-person team, "because Netflix does it", no automation) that override everything else.

Where to start (if you decide to go ahead): in this order, without skipping any: (1) the four teams —or however many you have— with clear ownership; (2) CI and an image of the monolith; (3) gateway in front and minimal observability; (4) table × area matrix and modular monolith; (5) first extraction by value/risk/dependencies with initial load, events, shadow and flag; (6) SLO and alert for the new service before calling it done; (7) template and library before the second service.

How to practice. The course environment is designed to be reproduced:

• Bring TechCorp up locally with the compose.yaml from 08-03 §2, get a Keycloak token and follow ord-88213 through Jaeger, Grafana and Loki as in 08-03 §5. Break things: stop payments-service and watch the watchdog and the DLQ; publish a malformed event with publishEvent.js and reprocess it; run p-802 out of stock.

• Suggested extension exercises, from smaller to larger: coupons and promotions (01-03, 02-02 ex. 2, 08-01 §11): first as an Orders module, then decide with criteria whether it deserves a service; returns: new order status, payment.refunded as a common branch, stock.restocked, email, audit; shipping: a shipping-service that consumes order.confirmed, talks to a fictional carrier (ACL, signed webhook, retries) and publishes order.shipped/order.delivered for Notifications and analytics to consume; v2 of order.created with upcasting and message pacts; Argo Rollouts for the Orders canary with analysis of slo:orders_error_ratio.
• Repeat module 6 on your own extension: metrics, SLO, alert, runbook and a game day in which a colleague breaks something without warning.

No URLs (they change); search by title and project. Books:

• Sam Newman, Building Microservices (2nd ed.) and Monolith to Microservices: the general reference and the strangler fig handbook TechCorp followed (modules 1, 2 and 8).
• Chris Richardson, Microservices Patterns: sagas, outbox, CQRS, API composition; the author's site microservices.io catalogs the patterns (02-05, 03-04).
• Eric Evans, Domain-Driven Design; Vaughn Vernon, Implementing Domain-Driven Design; Vlad Khononov, Learning Domain-Driven Design: bounded contexts, context map, aggregates (02-03).
• Martin Kleppmann, Designing Data-Intensive Applications: consistency, replication, messaging, the theoretical basis of 02-04 and 02-05.
• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns: messaging, DLQ, idempotency (03-02, 06-03).
• Michael Nygard, Release It! (2nd ed.): timeouts, circuit breaker, bulkhead, stability (06-03).
• Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook: SLOs, burn rate, on-call, postmortems (06-05).
• Nicole Forsgren, Jez Humble and Gene Kim, Accelerate: the DORA metrics (05-03, 08-01 §10).
• Matthew Skelton and Manuel Pais, Team Topologies: stream-aligned teams and the platform team (02-01, 08-04 §1.1).
• Jez Humble and David Farley, Continuous Delivery; Marko Lukša, Kubernetes in Action: the basis of modules 5 and 8.
• Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani, Software Architecture: The Hard Parts: granularity, data and sagas with explicit trade-offs.

Official documentation and projects worth keeping at hand: Node.js and Express; PostgreSQL and MongoDB; RabbitMQ (reliability, DLX and TTL guides); Docker and Compose; Kubernetes (concepts, Kustomize), Helm, kind, KEDA, Argo CD and Argo Rollouts, ingress-nginx, cert-manager, External Secrets Operator; GitHub Actions; Prometheus, Grafana, Loki, OpenTelemetry (JavaScript SDK) and Jaeger; Keycloak; Pact (including message pacts) and the Pact Broker; Trivy and Sigstore/cosign; OWASP API Security Top 10; The Twelve-Factor App; and the OpenAPI, AsyncAPI, RFC 7807 and W3C Trace Context specifications.

• Turning the best-practices list into dogma. Every item in section 3 has a lesson with its context and its trade-offs; applied without the context (for example, an outbox in a service that publishes nothing critical) it adds complexity without benefit. Read the lesson before imposing the practice.
• Copying TechCorp's final architecture instead of its method. Six services, RabbitMQ and Kubernetes are the answer to the five problems from 01-05 with 25 engineers; with three people and a changing domain, the right answer from the 01-04 matrix is a modular monolith.
• Confusing "phase 2" with "pending". Mesh, event sourcing, gRPC or Go have an activation criterion; tackling them before it is met is the "because Netflix does it" that 01-04 warned about.
• A postmortem without actions or actions without a date. The tables in section 1 are project postmortems; their value is in the "what we would do differently" column turned into tasks with an owner.
• Practicing only the happy path. The local environment is there to be broken: stop Payments, run out of stock, publish malformed events, rotate a secret. What you have not seen fail locally you will see fail in production.
• Tip: keep your own version of the tables in section 1 from the first day of your project, even if they are almost empty. The discipline of filling them in every quarter is worth more than any tool.

Apply the matrix from section 5 to a system you know (the one at your job, a personal project or, if you have none, a hotel booking system with 4 engineers). Answer the five questions with concrete data, state which recommendation comes out and, if it is "extract", which would be the first service and what your phase 0 would do.

A team describes its system like this: "We have eight services on Kubernetes. They share one PostgreSQL database with separate schemas per service, but the reporting service does JOINs across schemas. We deploy all eight together every two weeks because a change to the common-models library forces updating all of them. The services call each other over HTTP in a chain and, when the customers one is slow, everything is slow. Each service retries failed calls three times in a row." Identify every antipattern from section 2 that appears, rank them by the damage they do and propose the first action for each, with the reference lesson.

Marta has budget for two initiatives from the table in section 4 next semester. With the data from the course (08-01 §10-11, 08-03 §11, SECURITY.md), choose two, justify them with each one's criterion and explain why you rule out at least three others that look attractive.

Exercise 1. There is no single answer; the solution is the method. For the 4-engineer hotel: (1) one team, no one in the way → no; (2) probably no complete CI or observability → no; (3) bookings and billing have similar loads; perhaps the availability engine in high season → weak; (4) known domain → yes; (5) speed is held back by the lack of tests, not by deployment → no. Result: modular monolith with modules by capability (bookings, billing, availability, customers), CI, container, observability and SLIs starting now; review in 6-12 months. If your real system yields four "yes" with the prerequisites ready, the first service is the one with the clearest reason and the fewest dependencies (the "catalog" of your domain) and phase 0 is the list in section 5 ("where to start").

Exercise 2. By damage: (1) Shared database (the reporting service's JOINs cross schemas: any schema change breaks reports) → table × service matrix and a read DB for reports fed by events (02-02 §3.3, 02-04 §8); (2) Shared models library + distributed monolith (eight services deployed together because of common-models) → replace with per-service contracts and a technical-only versioned library; each service defines its DTOs (02-02 §6, 03-06); (3) Chained synchrony with immediate retries (everything is slow when customers is slow; three retries in a row multiply the load: retry storm) → timeouts with a budget, circuit breaker, retries with backoff only for transient errors, and replacing calls not needed in the request with events or read replicas (06-03, 02-04 §4, 03-02); (4) Joint deployment every two weeks (symptom, not cause) → disappears when 1-2 are solved; measure DORA to confirm it (05-03 §12). Not present (or unknown): fat gateway, secrets, cardinality; ask.

Exercise 3. A defensible answer: (a) FinOps — criterion "now": the bill is €2,760/month with identified levers of ~€800 (08-03 ex. 3); the initiative's cost is low (labels and a report); immediate return that also funds the rest. (b) Pending items in SECURITY.md (cosign at admission, PSA enforce, ESO for everyone) — criterion "next quarter"; known risk, bounded cost, and it unblocks the Payments audit which in turn will trigger the mesh. Ruled out: mesh/mTLS now — its criterion (audit or >12 services) is not met yet and it costs to operate (05-05); event sourcing — nobody has asked for the full history and the audit log from 07-03 covers what is sensitive; Go for Inventory — there is no measured cost or latency to justify it (Marta's rule); gRPC Orders↔Inventory — the saga meets its 60 s SLO with a p95 of 3 s; IDP — with 6 services and a README, it does not pay off. What matters is not the two chosen but that each rejection rests on the table's criterion and not on the appeal of the technology.

The journey, module by module. In module 1 we learned what a microservice is, what you gain and what you pay, how it compares with the monolith, when it makes sense to take the step, and we met TechCorp: a monolith with five problems and one function, createOrder, that did six things across five areas. In module 2 we designed: principles and coupling, decomposition with event storming and the table matrix, bounded contexts and the context map, one database per service and migration without dual write, and the choreographed saga with outbox and idempotency that replaced the transaction. In module 3 we made the services talk: REST contracts with 202, ETag and Idempotency-Key; RabbitMQ with its topology and its DLQs; gRPC and GraphQL as candidates; the gateway and the BFF; discovery and probes; versioning and pacts. In module 4 we wrote code: the template and the library, catalog-service, validated configuration, orders-service with its outbox and its consumers, and the test pyramid. In module 5 we packaged and deployed it: Docker and Compose, Kubernetes with Kustomize, CI/CD with GitHub Actions, Pact Broker and Argo CD, progressive deployments, and the honest evaluation of the mesh. In module 6 we made it operable: logs, metrics and traces; resilience and recovery; scaling; SLOs, alerts, on-call, runbooks and the INC-2031 postmortem. In module 7 we secured it in layers: Keycloak and JWT, TLS and signatures, validated code and GDPR, hardened platform. And in module 8 we brought it together: the migration told in order, the four missing services, the system deployed and operated, and these lessons.

Marta's words. "When I presented the plan in July 2025 they asked me why we didn't just rewrite the store in one go. Thirteen months later, the answer is in the numbers we never had to explain: not a single day without selling, eleven deployments a day, one serious incident that lasted forty minutes and taught us more than two years of Thursday nights. But what I value most isn't in the table: today every team knows what is theirs, measures it and improves it without asking permission. Microservices were the means; the end was an organization that could change the store every day without fear. If I had to sum the project up in one sentence for another CTO: don't start with the services, start with the homework; and don't delete anything on cutover day."

Luis's words. "I'll keep three things. First, that the best technical decision of the year was the least glamorous one: returning the stock and payments writes to their owner inside the monolith before moving a single line of server. Second, that almost everything that saved us in production was boring and was written before we needed it: the UNIQUE (order_id), the processOnce, the watchdog, the idempotency key toward the payment provider, the retry queue. And third, that the rule 'if it is done more than once per service, automate it before the second time' is easier to say than to follow —ci.yml got copied three times— and even so it is what lets a team of twenty-five people operate six services. To anyone just starting out: read createOrder from 01-05 again, now that you know what it became. The whole course is in the distance between those 80 lines and ord-88213 crossing four databases in three seconds."

For you. You have walked the same path as TechCorp, with its decisions and its stumbles. What you take with you is not a list of technologies —they will change— but a method: measure before deciding, do the homework before splitting, cut by capabilities and data, communicate through contracts and idempotent events, automate before the second use, deploy small and often, observe and agree on what "going well" means, secure in layers and learn in writing from every incident. Bring TechCorp up on your laptop, break it, extend it with coupons, returns or shipping, and then apply the method to your own system, starting with phase 0. Microservices are not the destination; they are a way for your organization to change its software with confidence, one order —and one deployment— at a time. Thank you for making it this far, and good luck with your own migration.