GuideIntermediate

Architecture Decisions And Tradeoffs

Learn the craft of deciding in architecture: how to make decisions under uncertainty, make trade-offs explicit, record them in Architecture Decision Records (ADRs), and defend them with evidence instead of opinion. The core idea of this guide is that architecture isn't a diagram, it's a set of decisions — each with a cost, a reversibility, and consequences — and that "there's no best, only trade-offs" between quality attributes. You build a decision matrix with weighted criteria and sensitivity analysis, write ADRs in Nygard format (Context/Decision/Consequences/Status), generate and test alternatives with spikes before committing, and protect each decision with a fitness function that fails automatically if the system crosses a threshold. You also work through the cost and reversibility of deciding: one-way vs two-way doors, the last responsible moment, and technical debt as a deliberate trade-off. Everything quantifiable is executed in Python, not eyeballed. You work on Mercado's open decisions — should orders and shipping communicate synchronously or through events? should the catalog be extracted into its own service? — and close with a project where you make and record a real architectural decision end to end.

64
lessons
8
modules
English · Spanish
available in
Yes
certificate
Free
access
NIEVA

Outcomes

What you'll be able to do

  • Understand that architecture is a set of decisions, not a diagram, and what makes a decision "architectural"
  • Recognize that there's no "best," only trade-offs between quality attributes (the -ilities: performance, scalability, maintainability, availability, security, cost), and quantify them instead of adjectivizing them
  • Write Architecture Decision Records (ADRs) in Nygard format: Context / Decision / Consequences / Status, and know when one ADR supersedes another
  • Build a decision matrix with weighted options and criteria, compute the score, and run a sensitivity analysis executed in Python
  • Generate at least three alternatives before deciding and reduce uncertainty with spikes or prototypes, instead of deciding on opinion
  • Write fitness functions: automated tests that measure a quality attribute (coupling, p99 latency, deploy size) and fail if it crosses a threshold
  • Evaluate the cost and reversibility of a decision: one-way vs two-way doors, the last responsible moment, and technical debt as a deliberate trade-off
  • Run a capstone project: make a real architectural decision for Mercado with at least three alternatives, a decision matrix, an ADR, and a fitness function

Before you start

What you need to bring

It's for you if...

  • Developers and tech leads who need to make and defend architectural decisions with evidence, not opinion
  • Teams with no ADR process who keep losing the "why" behind past decisions and end up repeating or contradicting them unknowingly
  • Architects who need to justify trade-offs to technical stakeholders with a reproducible method
  • Devs who want to move from "I just like X" to comparing options with a weighted matrix and protecting them with code

Requirements and materials

  • Experience designing or maintaining backend systems (services, APIs, databases)
  • Python to run the guide's decision matrices and fitness functions
  • No prior knowledge of any specific architectural pattern required — this guide decides BETWEEN them, it doesn't teach them in depth

Content

The syllabus, module by module

Open any of them to see its lessons.

Common questions

What people usually ask

Start whenever you like

Reviews

What students say

These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.

No approved reviews yet.

Be the first to share your experience!