Skip to content
Architecture Decisions

Architecture Decisions

Everything between a validated idea and an executable architecture blueprint — ADRs, PRD templates, cost estimation, system design, technology selection, decision frameworks.

48 results

Architecture Decision Records

ADR Format

The standard Markdown structure for an Architecture Decision Record.

Architecture Decision Records

ADR Template

A copy-paste starter file so authors spend time on content, not formatting.

Architecture Decision Records

Superseding a Decision

The correct way to change an accepted architectural decision without destroying history.

Architecture Decision Records

ADR Review Process

A lightweight gate so ADRs get genuine technical scrutiny, not just rubber-stamp approval.

Architecture Decision Records

Context & Impact Mapping

Map which parts of the system a decision touches before committing, so consequences are visible.

Architecture Decision Records

ADR Tooling

Tooling to generate, lint, and index ADRs so they stay consistent as the set grows past 20.

Architecture Decision Records

Linking ADRs to Code

Bi-directional links between the decision record and the code that implements it.

Architecture Decision Records

ADR Anti-Patterns

Common ways ADRs go wrong and how to spot them in review.

PRD Templates

PRD Structure

The canonical sections every Product Requirements Document should contain.

PRD Templates

User Story Format

The 'As a X, I want Y, so that Z' format and when to use it vs. job-stories.

PRD Templates

Acceptance Criteria

The precise, testable conditions that define 'done' for a user story.

PRD Templates

Non-Functional Requirements

The performance, security, and reliability targets that are invisible until they're missed.

PRD Templates

PRD Review Checklist

A pre-build checklist that catches under-specified PRDs before engineering wastes a sprint.

PRD Templates

Stakeholder Alignment

Getting explicit sign-off from every party that will be affected by the feature.

PRD Templates

PRD Versioning

How to handle PRD changes after build starts without silently mutating the spec.

PRD Templates

PRD vs RFC

When to write a Product Requirements Doc vs an engineering Request for Comments.

Cost Estimation

Cloud Cost Model

A spreadsheet or script that maps your architecture to a monthly dollar figure before you build it.

Cost Estimation

Total Cost of Ownership

Include ops, on-call, and migration cost — not just the cloud invoice — when comparing options.

Cost Estimation

Cost Per Request

The unit economics metric that tells you if the architecture scales financially, not just technically.

Cost Estimation

Reserved Capacity

Commit to capacity you'll use for 1+ years to cut 30-70% off the compute bill.

Cost Estimation

Cost Optimization

The ongoing practice of finding and killing waste without degrading performance.

Cost Estimation

FinOps Practice

The organizational practice of making cloud cost everyone's responsibility, not just finance's.

Cost Estimation

Cost Attribution

Tagging strategy so every dollar of cloud spend maps to a team, product, and environment.

Cost Estimation

Spot & Preemptible

Use 60-90% discounted spare capacity for workloads that tolerate interruption.

System Design

Capacity Planning

Size every component for the peak load you expect, with headroom, before you build it.

System Design

Data Modeling

Choose the storage model and schema that make your access patterns fast and your future changes cheap.

System Design

API Design

The contract between your service and its consumers — design it for stability, clarity, and evolution.

System Design

Caching Strategy

Decide what to cache, where, and how to invalidate — the three questions that determine if cache helps or hurts.

System Design

Scaling Patterns

The architectural shapes that let a system grow — vertical, horizontal, sharding, partitioning — and when each applies.

System Design

Consistency Trade-offs

The CAP/PACELC choice between strong and eventual consistency, and how to pick per data type.

System Design

Idempotency Design

Make retries safe so the system can self-heal without creating duplicates.

System Design

Backpressure

Signal upstream to slow down instead of queuing unboundedly or dropping requests.

Technology Selection

Build vs Buy

Decide whether to build a capability in-house or use a managed service / SaaS, based on total cost and strategic value.

Technology Selection

Managed vs Self-Hosted

Choose between a cloud-managed service and self-hosting the open-source equivalent, based on ops capacity and cost.

Technology Selection

Language Selection

Pick the programming language based on the problem shape, team expertise, and ecosystem — not fashion.

Technology Selection

Database Selection

Match the database to the workload — OLTP, OLAP, KV, time-series, search — not to 'the one we know'.

Technology Selection

Framework Selection

Pick the framework that's boring and well-documented over the one that's novel and clever.

Technology Selection

Vendor Lock-in

Assess and minimize the cost of leaving a vendor, without refusing to use vendors at all.

Technology Selection

Observability Tooling

Pick the metrics/tracing/logging stack that lets you debug production in minutes, not hours.

Technology Selection

Deployment Platform

Choose where code runs — VMs, containers, functions, or PaaS — based on the workload shape and team capacity.

Decision Framework

Decision Triggers

Know the events that should trigger an architecture decision vs. just a task.

Decision Framework

Decision Roles

Assign who writes, who reviews, and who decides — so decisions don't stall and aren't unilateral.

Decision Framework

Reversibility

Rate each decision by how expensive it is to reverse, and spend effort proportional to that cost.

Decision Framework

Decision Criteria

Define the dimensions you'll evaluate alternatives on, before you look at the alternatives.

Decision Framework

Alternatives Analysis

Always consider at least 2 alternatives — the first idea is rarely the best, and 'no alternatives' is a red flag.

Decision Framework

Decision Documentation

Write the ADR so a future engineer (or you in 6 months) can understand not just what was decided, but why.

Decision Framework

Decision Review

Review past decisions periodically to catch ones that are outdated, and to learn from ones that aged well or poorly.

Decision Framework

Escalation Path

Define when a decision must escalate beyond the team — to avoid both stuck decisions and rogue decisions.

Six Subdomains

48 decision methods covering the full path from idea to architecture blueprint.

Next Step

Design

UI/UX patterns, design systems, dashboard templates and accessibility guidelines.

Go to