Choosing Architecture & SDLC

This page is a decision aid. Given requirements — team size, domain complexity, latency, consistency, release cadence, compliance — pick an architecture style and an SDLC model that fit. No table replaces judgment, but tables prevent pattern tourism.

Always write the drivers first (Requirements), then consult these matrices, then record the choice as an ADR (Best Practices).

• 1. List Must NFRs and constraints on a whiteboard.
• 2. Score options (monolith, services, EDA, serverless) against each Must.
• 3. Eliminate options that fail a Must.
• 4. Among survivors, prefer lower complexity / higher reversibility.
• 5. Draft ADR with alternatives and revisit triggers.
• 6. Pick SDLC that matches uncertainty and compliance.
• 7. Schedule a revisit date (e.g., after 3 months metrics).

Architecture is not permanent. Revisit when:

• Team count or topology changes significantly.
• An NFR repeatedly burns SLO/error budgets.
• Release coupling blocks independent value streams.
• Compliance scope expands (new certification).
• Cost model breaks (cloud bill or engineering time).

• Copying Netflix/Amazon architecture without their scale or platform investment.
• Choosing microservices to "force modularity" — modularity is cheaper in-process first.
• Picking Scrum while stakeholders refuse to attend reviews — process without feedback.
• Ignoring ops maturity — distributed styles need paved roads first.
• Optimizing for hypothetical hypergrowth while missing near-term delivery.
• Never writing ADRs — decisions evaporate; new hires re-litigate forever.
• Treating the choosing table as destiny — context beats slogans.

Notice each scenario starts from drivers, not from a favorite pattern. When you present a recommendation, lead with the same structure: drivers → options → choice → risks → revisit triggers.

Next: Best Practices. Also Requirements, Mastery.