Distributed System Architecture Decision Brief

Role: Lead Software Architect and Technical Communication Specialist

Context

• Subsystem Name: {{subsystem_name}}
• Primary Architectural Driver: {{architectural_driver}}
• Proposed Pattern: {{proposed_pattern}}
• Evaluated Alternatives: {{evaluated_alternatives}}
• Latency SLA: {{latency_sla}}
• Impacted Services: {{impacted_services}}

Task

Synthesize an Architecture Decision Record (ADR) brief that rigorously justifies the adoption of {{proposed_pattern}} for {{subsystem_name}} while addressing trade-offs against {{evaluated_alternatives}} and SLA constraints.

Method

1. Frame the core operational problem driving architectural review using {{architectural_driver}}.
2. Detail the structural design of {{proposed_pattern}} and how it solves data consistency and throughput requirements.
3. Compare the proposed approach against {{evaluated_alternatives}} across maintenance cost, scalability, and operational complexity.
4. Map potential bottlenecks against the target {{latency_sla}} under peak load scenarios.
5. Enumerate integration dependencies, data schema shifts, and blast radiuses across {{impacted_services}}.
6. Identify architectural risks, single points of failure, and corresponding observability guardrails.
7. Outline the formal decision consequence profile including technical debt retirement and new operational overhead.

Constraints

• MUST express trade-offs using objective technical metrics rather than qualitative preference.
• MUST NOT exceed 700 words across all sections.
• All references to {{impacted_services}} must identify the interface contract altered.
• Structural diagrams or flow descriptions must be written in valid ASCII or concise step notation.
• Must explicitly state compliance with {{latency_sla}}.

Output format

Generate the decision brief with the following distinct sections:

1. Status and Context Statement (Max 80 words)
2. Architectural Decision Summary (Clear structural narrative)
3. Trade-off Matrix (Table comparing Proposed Pattern vs {{evaluated_alternatives}} across 4 criteria)
4. System Topology Impact (Impact list covering {{impacted_services}})
5. Observability and SLA Compliance Guardrails (Bulleted checklist)

Self-review

• Confirm {{architectural_driver}} is directly resolved by the proposed design.
• Ensure each alternative in {{evaluated_alternatives}} has a defined drawback.
• Validate that impacts on {{latency_sla}} are explicitly documented with mitigation steps.
• Check that no vague architectural assertions are made without reasoning.