ADR examples
These ADR examples are written as realistic architecture decision record samples—tradeoffs, status, and consequences included. Browsing a few is one of the fastest ways to calibrate what “enough” looks like. If you need phrasing for a database or platform choice, a good architecture decision record example here is the PostgreSQL default; the Redis and event-driven pages show other shapes of risk. For broader sets of software architecture decision examples, use the list below, then read architecture decision log when you are ready to think about the index, not just one file. Each page uses a Nygard-style flow; the generator can output MADR, Y-Statement, Outcome-First, or ISO 42010 Companion when that fits your process.
Default relational database for new services (PostgreSQL)
An architecture decision record example for a database default: one engine to simplify operations, with explicit carve-outs.
Incremental monolith to services (bounded cutovers)
Strangler pattern with data ownership rules; non-goals are explicit to avoid a big-bang rewrite.
Use Redis for short-lived application caching
Read-through cache for latency, not a source of truth: invalidation and correctness stay first-class in review.
Introduce event-driven communication for order lifecycle updates
Proposed: domain events to loosen coupling; eventual consistency and observability are called out as consequences.
Use a managed authentication provider
Security and time-to-delivery over owning auth internals; vendor dependency and custom flows are acknowledged.
Architecture decision log — how a whole set of ADRs is indexed and maintained over time.
Start from the markdown template or the generator when you write the first file in your own repository.