We reach the end of the course, and nothing consolidates what has been learned better than designing a complete system from scratch, applying—with justification—the decisions we have been studying. In this lesson we will act as the architecture team of a fictional company, MercadoFiatc, which needs to build an e-commerce platform. We will start from the business requirements, translate them into quality attributes, choose an architectural style with its justification, model the data, define deployment and observability, and record the key decisions as ADRs. We are not looking for "the" correct answer—in architecture it almost never exists—but rather to show coherent reasoning: each decision derives from a requirement and consciously accepts its trade-offs. This case closes the course by integrating the modules on styles, data, communication, deployment, governance, and evolution.

1. MercadoFiatc's requirements
2. From requirements to quality attributes
3. Choosing the architectural style
4. C4 diagram of the system
5. Data design
6. Communication between components
7. Deployment
8. Observability
9. Recorded decisions (ADR) and evolution
10. Common Mistakes and Tips
11. Exercises
12. Course conclusion

The business presents us with these functional requirements and constraints:

• A browsable product catalog with search, tens of thousands of references.
• A shopping cart and payment process (checkout) with an external gateway.
• Order management and its status (confirmed, preparing, shipped, delivered).
• Product recommendations.
• Very strong traffic peaks during campaigns (Black Friday): catalog browsing can multiply by 50, while payments grow much less.
• A team of about 25 people, organized into 4 squads.
• A limited operating budget: they do not want to pay the complexity of a distributed system where it does not add value.

The first step of any serious architecture is to translate business requirements into measurable quality attributes, because it is they—and not the features—that most condition the design.

Notice the key tension: we need granular scaling (catalog grows much more than payments) and squad autonomy, which pushes toward microservices; but the limited operating cost and the order's consistency push toward the monolith. The architecture will be born from balancing those forces.

We do not jump straight to "microservices for everything." We evaluate options:

We choose the mixed and evolutionary approach, fully aligned with what we have learned: we start with a modular monolith well delimited by domains (Catalog, Cart, Orders, Payments, Recommendations) and extract as a microservice only what has disparate scaling or availability needs. Specifically:

• Catalog is extracted early: it is the one that suffers the x50 during a campaign and is worth scaling on its own.
• Recommendations is extracted: it is optional, can fail without breaking the purchase, and evolves quickly.
• Cart, Orders, and Payments remain together in the modular monolith at first, because they share transactions and strong consistency; extracting them early would bring sagas and pain without a clear benefit.

This decision directly applies the MonolithFirst rule and the Strangler Fig pattern: the modular monolith is the starting point, and extraction is incremental and guided by real pain.

We use the C4 model (Context, Containers, Components, Code) to communicate the design to different audiences. We show the Containers level, the most useful one for architecture.

Let's read the diagram, which synthesizes almost all the decisions:

• The API Gateway also acts as a Strangler Facade: it routes each request to the extracted service or to the monolith. It is the point from which we will keep strangling if needed.
• Catalog and Recommendations are independent containers with their own database: they can be scaled and deployed separately.
• The modular monolith groups Cart, Orders, and Payments over a single database, allowing local ACID transactions during checkout.
• Communication with Recommendations is asynchronous via events (OrderConfirmed via broker): this way the order does not depend on Recommendations being available.

We apply the principle of one database per service where there are separate services, and strong consistency where the transaction requires it:

The most delicate decision is the consistency between order and payment. Since they live in the same monolith over the same relational DB, confirming the order and recording the payment happens in a single local ACID transaction: either everything is done or nothing is. This avoids distributed sagas, which we would only introduce if we later extracted Payments. The relationship with Recommendations, on the other hand, is eventual consistency: after confirming the order an event is published and Recommendations is updated with a slight delay, which is perfectly acceptable for suggested data.

We combine communication styles according to the nature of each interaction:

• Synchronous (REST/HTTP) through the gateway for client requests: browsing the catalog, viewing the cart, checking out. The user expects an immediate response.
• Asynchronous via events for internal integrations that tolerate delay: OrderConfirmed triggers the update of Recommendations and, in the future, of Billing.
• Anti-Corruption Layer in the Catalog service if it were necessary to integrate with a legacy PIM (Product Information Management) with an old data model.

This event contract is the public boundary between the monolith and the consumers (Recommendations today, Billing tomorrow). Defining it explicitly and versioned (version: 1) is essential: consumers depend on its shape, so an incompatible change would require a version: 2. The event carries only what is necessary and does not include sensitive personal data beyond identifiers, which also helps respect data minimization.

The deployment reflects the mixed architecture and the contained budget:

• Containers (Docker) orchestrated with Kubernetes, but with few pieces: monolith, catalog, recommendations, gateway, and broker. We do not multiply services unnecessarily.
• Independent horizontal scaling: Catalog is configured with aggressive autoscaling (many replicas during a campaign); the monolith and the rest, with more moderate scaling.
• Independent deployment per squad: each container has its own pipeline, so that the Catalog squad deploys without coordinating with the Orders squad. This satisfies the autonomy attribute.
• Progressive deployment strategy (canary or blue-green) to reduce the risk in each release, with the possibility of rolling back.

This manifest materializes the granular scalability requirement: the catalog can go from 3 to 60 replicas automatically when the CPU exceeds 65% usage, absorbing the campaign peak, while the rest of the system maintains its usual capacity. It is exactly the benefit that justified extracting Catalog as a separate service.

A system with distributed pieces and asynchronous events is opaque without observability. We implement the three pillars:

• Structured logs (JSON) centralized, with a common traceId across all pieces.
• Metrics (Prometheus/Grafana): p95 latency per service, error rate, broker queue depth, active replicas.
• Distributed traces (OpenTelemetry): follow a checkout request through the gateway, the monolith, and the broker, seeing where the time goes.

Observability is not a luxury: it is the prerequisite for evolving safely. Without catalog latency metrics, we would not know whether autoscaling works; without traces, debugging the Recommendations event flow would be guesswork. Moreover, the metrics feed continuous fitness functions: an alert if the checkout p95 exceeds 300 ms is a fitness function that watches the architectural health in production.

We close the design by documenting the key decisions as ADRs, just as we saw in the governance lesson:

• ADR-001: Start with a modular monolith and extract services only out of pain (scaling/availability). Consequence: low initial cost; we accept refactoring boundaries later.
• ADR-002: Extract Catalog as an independent service. Consequence: granular scaling; the cost of its own DB and pipeline.
• ADR-003: Asynchronous event-based communication toward Recommendations. Consequence: decoupling and availability; eventual consistency and mandatory idempotency.
• ADR-004: Keep Cart, Orders, and Payments together with a local ACID transaction. Consequence: strong consistency without sagas; re-evaluate if Payments needs to scale separately.

And we protect the architecture with fitness functions: ArchUnit tests that forbid cycles between the monolith's modules and that prevent the domain from depending on the infrastructure, plus a continuous latency fitness function in production. This way, the architecture is documented (ADR) and monitored (fitness functions): it can evolve without degrading. When a module of the monolith starts to hurt, the Strangler Facade is already in place to extract it incrementally.

• Starting with the solution and not with the quality attributes. Designing "with microservices" before knowing what needs to scale is putting the answer before the question.
• Extracting services out of fashion. Each extracted service costs operations, observability, and consistency. Extract only where the quality attribute justifies it (Catalog yes, Payments not yet).
• Forgetting consistency when separating. The moment you split a transaction across services, you enter sagas and eventual consistency. Be clear about this before cutting.
• Designing without observability. A mixed system without traces or metrics is impossible to evolve safely.
• Not documenting the decisions. Without ADRs, a year from now nobody will remember why Payments is in the monolith and someone will "fix it," creating a mess.
• Tip: check that each design decision can be traced back to a specific requirement or quality attribute. If you cannot, it is probably superfluous.

Exercise 1. The business adds a requirement: "sending transactional emails (order confirmation) must not slow down checkout and must be retryable if the email provider fails." How would you integrate it into the proposed architecture?

Exercise 2. After six months, the metrics show that Payments suffers its own peaks and the team wants to deploy it separately. Describe, using what you have learned, how you would extract it from the monolith and what new consistency problem appears.

Exercise 3. Justify why Catalog uses a search- and read-oriented store, while Orders uses a relational ACID one. Relate each choice to a quality attribute.

Solution 1. Through asynchronous event-based communication: checkout publishes OrderConfirmed (which already exists) and a notifications consumer sends the email in a deferred manner. This way checkout does not wait for the email; if the provider fails, the consumer retries from the queue. Idempotency is advisable to avoid sending the email twice if the event is redelivered.

Solution 2. By applying Branch by Abstraction inside the monolith (a PaymentsService interface), then building the Payments microservice with its own DB and switching with feature flags via the gateway (Strangler). The new problem: order confirmation and payment recording no longer share an ACID transaction; the need arises for a saga with compensation (e.g., cancel the order if the payment fails) and eventual consistency between the two.

Solution 3. Catalog prioritizes read performance and scalability (fast search over tens of thousands of references under x50 peaks), hence a store optimized for search and replicas. Orders prioritizes consistency: checkout crosses cart, order, and payment in an operation that must be all-or-nothing, which requires the ACID transactions of a relational store.

With this case study we close the Application Architecture course. We have seen how a good design does not come from choosing the trendy technology, but from disciplined reasoning: translating business requirements into measurable quality attributes, choosing the style that best balances them—at MercadoFiatc, a modular monolith that evolves by extracting only what justifies it—modeling the data according to consistency needs, combining synchronous and asynchronous communication, deploying with granular scaling where it matters, and sustaining it all with observability. And, above all, we have closed the circle of the final module: documenting the decisions with ADRs, protecting them with fitness functions, and leaving the Strangler Facade ready to keep evolving incrementally and in a guided way.

Throughout the course you have walked the complete path: what architecture is, monolithic and distributed styles, layers and hexagonal architecture, data management and communication, deployment, and finally evolution and governance. The underlying lesson is always the same: in architecture there are no perfect solutions, only well-reasoned trade-offs. Your job as an architect is not to eliminate the trade-offs, but to choose them consciously, justify them, and leave the system ready to change when today's trade-offs stop serving. Congratulations on completing the course.