Behavioral & Leadership (50 Qs)•Part 3: Engineering Leadership, Code Quality & Collaboration (26 - 36)
How do you write and defend an Architectural Decision Record (ADR) or Request for Comments (RFC)?
In Simple Words: An ADR or RFC builds organizational consensus asynchronously. It documents the problem, constraints, evaluated options, chosen path, and explicit trade-offs.
The RFC Defense Strategy:
- Pre-wire with Key Stakeholders: Never drop a massive 20-page RFC unexpectedly. Review initial drafts 1-on-1 with senior architects and impacted leads.
- Steel-man Alternative Options: Dedicate serious analysis to why other technologies were rejected.
- Separate Decisions from Opinions: Anchor choices to measurable SLAs, operational overhead, and budget.
Practical Script & Summary Template
markdown
# ADR-042: Adoption of Redis Cluster for Distributed Session Storage
## Status
ACCEPTED (Date: 2026-03-15)
## Context & Problem Statement
Our current in-memory Node.js session store prevents horizontal auto-scaling across multiple ECS Fargate containers. We require a centralized session store supporting 50,000 active sessions with sub-5ms read latency.
## Decision Drivers
- Read latency must be under 5ms at p99.
- Automatic TTL expiration for inactive sessions.
- Zero maintenance operational burden on a 4-person team.
## Considered Options
1. PostgreSQL (sessions table) - Rejected: High connection overhead and disk I/O cost.
2. DynamoDB - Rejected: Exceeds budget constraints under high-frequency session renewal writes.
3. Amazon ElastiCache Redis - **SELECTED**: Native TTL, sub-millisecond latency, fully managed.
## Consequences & Trade-offs
- Positive: Sub-2ms p99 session reads, horizontal container scaling unlocked.
- Trade-off: Requires configuring Redis connection retry logic and VPC peering.