57 lines
1.7 KiB
Markdown
57 lines
1.7 KiB
Markdown
# ADR-0022: Cache Implementation
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Context
|
|
The platform needs caching for:
|
|
- Performance optimization (reduce database load)
|
|
- Frequently accessed data (user permissions, roles)
|
|
- Session data (optional)
|
|
- Query results
|
|
|
|
Options considered:
|
|
1. **Redis** - Industry standard, feature-rich
|
|
2. **In-memory cache** - Simple, no external dependency
|
|
3. **Memcached** - Simple, but less features than Redis
|
|
4. **No cache** - Simplest, but poor performance at scale
|
|
|
|
## Decision
|
|
Use **Redis** as the primary cache with **in-memory fallback**:
|
|
|
|
1. **Primary**: Redis for production
|
|
2. **Fallback**: In-memory cache for development/testing
|
|
3. **Interface abstraction**: `Cache` interface allows swapping implementations
|
|
4. **Use cases**: Permission lookups, role assignments, query caching
|
|
|
|
**Rationale:**
|
|
- Industry standard, widely supported
|
|
- Rich feature set (TTL, pub/sub, etc.)
|
|
- Can be shared across instances (multi-instance deployments)
|
|
- Good performance
|
|
- Easy to abstract behind interface
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
- High performance
|
|
- Shared across instances
|
|
- Rich feature set
|
|
- Easy to scale horizontally
|
|
- Abstraction allows swapping implementations
|
|
|
|
### Negative
|
|
- Additional infrastructure dependency
|
|
- Network latency (minimal with proper setup)
|
|
- Need to handle Redis failures gracefully
|
|
|
|
### Implementation Notes
|
|
- Install: `github.com/redis/go-redis/v9`
|
|
- Create `pkg/infra/cache/cache.go` interface
|
|
- Implement `internal/infra/cache/redis_cache.go`
|
|
- Implement `internal/infra/cache/memory_cache.go` for fallback
|
|
- Use connection pooling
|
|
- Handle Redis failures gracefully (fallback or error)
|
|
- Configure TTLs appropriately (e.g., 5 minutes for permissions)
|
|
|