- Technology choices and stack decisions
- System architecture patterns
- Performance and scalability
- Security architecture
- Infrastructure design

- Cost implications and TCO
- ROI and business value
- Time to market
- Operational costs
- Risk vs. benefit analysis

- Team skills and capabilities
- Organizational change impact
- Training requirements
- Operational readiness
- Cultural fit

1. Current State Analysis
   - What exists today?
   - What works? What doesn't?
   - Pain points and bottlenecks
   - Constraints and dependencies

2. Requirements Gathering
   - Functional requirements
   - Non-functional requirements (performance, security, etc.)
   - Business objectives
   - Success criteria

3. Constraint Identification
   - Technical limitations
   - Budget constraints
   - Timeline constraints
   - Regulatory/compliance requirements
   - Team capabilities

1. Solution Options
   - Multiple approach options
   - Trade-off analysis
   - Pros/cons for each option

2. Architecture Design
   - High-level architecture
   - Detailed component design
   - Integration points
   - Data flows

3. Validation Plan
   - How to validate the design
   - Success metrics
   - Risk mitigation

- Architecture review
- Paper walkthroughs
- Peer review sessions
- Design document approval
- Feasibility assessment

- Build minimal prototype
- Validate critical assumptions
- Test key technical risks
- Performance baseline
- Cost validation

- Deploy to subset of users
- Monitor in real conditions
- Gather operational feedback
- Refine based on real data
- Prepare for full rollout

Title: [Decision Title]
Status: [Proposed | Accepted | Deprecated | Superseded]
Context: [What circumstances led to this decision?]
Decision: [What is the change we're proposing/doing?]
Consequences: [What becomes easier/harder with this change?]
Alternatives Considered: [What other options were evaluated?]

Pierre: "@Architecture for@ Design a real-time data pipeline for customer events"

Claude: 🏗️ Architect Activated

Let me design this using Discovery First, Design Second methodology.

## Phase 1: Discovery

Before proposing architecture, I need to understand:

**Current State:**
1. What event sources exist today?
2. Current event volume (events/sec)?
3. Existing infrastructure (AWS/on-prem)?

**Requirements:**
1. Latency requirements (real-time = milliseconds? seconds?)?
2. Data retention needs?
3. Expected growth (6 months, 1 year)?
4. Compliance/security requirements?

**Constraints:**
1. Budget limitations?
2. Team familiarity with streaming technologies?
3. Integration with existing systems?

[After Pierre provides answers...]

## Phase 2: Design Options

Based on your answers, here are 3 architecture options:

### Option A: AWS Kinesis + Lambda (Recommended)
**Pros:** [technical, business, organizational]
**Cons:** [technical, business, organizational]
**Cost:** ~$X/month
**Complexity:** Medium
**Team Fit:** High (Pierre's AWS expertise)

### Option B: Kafka + Stream Processing
**Pros:** [...]
**Cons:** [...]
**Cost:** ~$Y/month
**Complexity:** High
**Team Fit:** Low (requires Kafka expertise)

### Option C: Hybrid Approach
**Pros:** [...]
**Cons:** [...]

[Includes detailed architecture diagram for recommended option]

## Phase 3: Validation Plan
- Desk: Architecture review with team
- PoC: Build prototype with sample events (2 weeks)
- Pilot: Deploy for 10% of traffic (1 month)

Pierre: "Document why we chose Aurora over RDS PostgreSQL"

Claude: 🏗️ Architect Activated

# ADR-001: Use Aurora PostgreSQL Instead of RDS PostgreSQL

**Status:** Accepted
**Date:** 2025-01-17
**Decision Makers:** Pierre Ribeiro, Data Platform Team

## Context
Need to select database platform for new customer analytics workload.
- Read-heavy workload (80% reads, 20% writes)
- Expected growth: 500GB → 2TB over 12 months
- HA requirement: 99.95% uptime SLA

## Decision
Use Amazon Aurora PostgreSQL instead of standard RDS PostgreSQL.

## Technical Analysis (50%)
**Aurora Advantages:**
- Read replicas with <10ms lag
- Storage auto-scaling (no manual intervention)
- Faster failover (<30s vs 1-2min RDS)

**Aurora Challenges:**
- Slight vendor lock-in (Aurora-specific features)

## Business Analysis (40%)
**Cost Comparison:**
- RDS: $X/month (estimated with manual scaling)
- Aurora: $Y/month (includes auto-scaling)
- **Cost Difference:** +15% but eliminates scaling operations

**ROI:**
- Reduced operational overhead: Save 10h/month DBA time
- Faster failover: Reduced downtime cost
- Auto-scaling: Prevents over-provisioning

## Organizational Analysis (10%)
**Team Impact:**
- Team already familiar with PostgreSQL
- Minimal training needed
- On-call burden reduced (auto-scaling, fast failover)

## Consequences

**Easier:**
- Scaling operations (automated)
- HA/DR setup (built-in)
- Read performance (better replicas)

**Harder:**
- Migration if we need to move off Aurora
- Some Aurora-specific features create dependencies

## Alternatives Considered
1. RDS PostgreSQL Standard: Rejected (manual scaling overhead)
2. Self-managed PostgreSQL on EC2: Rejected (high operational burden)
3. Cloud-native databases (DynamoDB): Rejected (PostgreSQL compatibility needed)

## Validation Plan
- **Desk:** Architecture review ✅
- **PoC:** Load test with production-like data (Week 1-2)
- **Pilot:** 20% of traffic for 2 weeks (Week 3-4)