# {Feature/Pattern Name}

**Concept**: [One-line description of what this design addresses]
**Created**: YYYY-MM-DD
**Status**: Proposal | Design Specification | Implemented

---

## Overview

[High-level description of what this design document covers and why it exists. Provide context about the problem space and the importance of this design decision.]

**Example**: "This document describes the authentication flow for multi-tenant access, enabling secure per-user data isolation across the system."

---

## Problem Statement

[Clearly articulate the problem this design solves. Include:]
- What challenge or limitation exists?
- Why is this a problem worth solving?
- What are the consequences of not solving it?

**Example**: "Without proper multi-tenant isolation, users could potentially access each other's data, creating security vulnerabilities and privacy concerns."

---

## Solution

[Describe the proposed solution at a conceptual level. Include:]
- High-level approach
- Key components involved
- How the solution addresses the problem
- Alternative approaches considered (and why they were rejected)

**Example**: "Implement row-level security using user_id as a tenant identifier, enforced at both the database and application layers."

---

## Implementation

[Provide technical details needed to implement this design. Include:]
- Architecture diagrams (as ASCII art or references)
- Data structures and schemas
- API interfaces
- Code examples (use placeholder names)
- Configuration requirements
- Dependencies

**Example**:
```typescript
interface TenantContext {
  userId: string;
  permissions: string[];
}

class DataService {
  constructor(private context: TenantContext) {}
  
  async getData(id: string): Promise<Data> {
    // Implementation with tenant filtering
  }
}
```

---

## Benefits

[List the advantages of this approach:]
- Benefit 1: [Description]
- Benefit 2: [Description]
- Benefit 3: [Description]

**Example**:
- **Security**: Complete data isolation between tenants
- **Scalability**: Horizontal scaling without data mixing concerns
- **Compliance**: Meets data privacy regulations (GDPR, etc.)

---

## Trade-offs

[Honestly assess the downsides and limitations:]
- Trade-off 1: [Description and mitigation strategy]
- Trade-off 2: [Description and mitigation strategy]
- Trade-off 3: [Description and mitigation strategy]

**Example**:
- **Performance**: Additional filtering adds query overhead (mitigated by proper indexing)
- **Complexity**: More complex queries and testing requirements
- **Migration**: Existing data requires backfill with tenant identifiers

---

## Dependencies

[List any dependencies this design has:]
- External services or APIs
- Other design documents
- Infrastructure requirements
- Third-party libraries

---

## Testing Strategy

[Describe how to verify this design works correctly:]
- Unit test requirements
- Integration test scenarios
- Security test cases
- Performance benchmarks

---

## Migration Path

[If this changes existing functionality, describe the migration strategy:]
1. Step 1: [Description]
2. Step 2: [Description]
3. Step 3: [Description]

---

## Future Considerations

[Note any future enhancements or related work:]
- Future enhancement 1
- Future enhancement 2
- Related design documents to create

---

**Status**: [Current implementation status]
**Recommendation**: [What should be done next - implement, review, revise, etc.]
**Related Documents**: [Links to related design docs, milestones, or tasks]