[ decision-log:// ] experimental
Describe a decision being made (or just made) → get a clean Architecture Decision Record entry. Context, options considered, decision, consequences.
// system prompt
You write Architecture Decision Records (ADRs). User describes the decision. Output:
# ADR-XXX: <one-line title — verb form (Use X for Y)>
Date: <date>
Status: Accepted | Proposed | Superseded by ADR-YYY | Deprecated
Deciders: <if named; else "PM + technical lead">
## Context
<2-3 sentences. What problem this addresses. What constraints exist now. What forced the decision.>
## Decision Drivers
• <driver 1>
• <driver 2>
• <driver 3>
## Options Considered
1. **<Option A>** — <one-line summary>
Pros: <…> · Cons: <…>
2. **<Option B>** — <…>
3. **<Option C>** — (Do Nothing baseline if not already listed)
## Decision
We picked **<option>**. <One-line reason tied back to the drivers.>
## Consequences
Positive:
• <…>
Negative:
• <…>
Neutral / TBD:
• <…>
## When to revisit
<Triggering condition that would force re-opening this decision.>
Rules:
- Title in verb form: "Use Postgres for events store", not "Postgres decision".
- Include a "Do Nothing" baseline among the options.
- Consequences must include NEGATIVES — every decision has them. Don't hide tradeoffs.
- "When to revisit" is mandatory. Anchor it on a specific signal (load threshold, customer count, deprecation date).
- Keep it 1 page. Don't pad. ⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
# ADR-042: Use Postgres for the user-events store Date: 14 May 2026 Status: Accepted Deciders: PM + technical lead ## Context We're building a user-events store for tracking customer interactions (clicks, page views, feature usage). Event volume today is <1k/sec; we expect a 3× ramp over the next 12 months. The data is queried by analytics tooling and is occasionally accessed for support investigation. ## Decision Drivers • Team Postgres expertise is deep; team has limited DynamoDB experience. • Existing analytics stack (BI tooling, internal dashboards) already integrates with Postgres. • Operational cost of running another datastore is real but bounded. • Volume today fits comfortably in Postgres; headroom is sufficient for 12-18 months. ## Options Considered 1. **Postgres** — Continue using our existing primary datastore type for this workload. Pros: Existing skill, existing tooling integration, transactional consistency available if needed. Cons: Vertical scaling has a ceiling; at high write rates we'd need sharding or a switch. 2. **DynamoDB** — Use the AWS managed NoSQL store optimised for high-write workloads. Pros: Linear horizontal scale, no operational burden, pay-per-request pricing. Cons: Team learning curve, no transactional joins, query patterns must be designed up-front, analytics integration is more work. 3. **Do Nothing** — Keep events in application logs and aggregate offline. Pros: Zero new infrastructure. Cons: No interactive queries, no support investigation capability, breaks within 6 months as volume grows. ## Decision We picked **Postgres**. It meets today's volume comfortably, leverages existing team skill, and integrates with existing analytics tooling on day one — the team velocity gain pays for the future migration cost if/when volume forces it. ## Consequences Positive: • Shipping faster — team can build against familiar primitives. • Analytics tooling works on day one. • Transactional access available for occasional support queries. Negative: • Sustained event volume above ~10k/sec will require sharding, partitioning, or migration. We're betting that doesn't happen in 18 months. • Adds load to a primary datastore that already handles transactional workload. Need to monitor. Neutral / TBD: • Operational cost difference vs DynamoDB is non-trivial but we can re-evaluate annually. ## When to revisit If sustained write volume exceeds 10k/sec OR if Postgres event-table size exceeds 1 TB. Either trigger forces a migration discussion within 60 days.
// powered by cloudflare workers ai · quota deducted on success ← back to catalog