System Configuration
Platform-wide configuration management with multi-tenant support
Background
Centralized system configuration service managing multi-tenant settings, feature flags, and admin access control. Must support configuration inheritance where tenant-specific overrides take precedence over platform defaults, with minimal latency on config reads.
Architecture
Admin UI → go-zero gRPC API → MySQL (10 tables) → Redis cache layer. Config reads: Redis → fallback MySQL. Writes: MySQL → invalidate Redis → OpLog audit entry.
Key Implementations
Multi-Tenant Config Inheritance
Implements a layered configuration system where platform defaults can be overridden at the tenant level, with tenant-specific values taking precedence.
Why: Different tenants require different settings (currency, limits, features) while sharing a common baseline to reduce configuration burden.
Active Member Auto-Init with Distributed Lock
Automatically initializes new active member records on first interaction, protected by a distributed lock to prevent duplicate creation.
Why: Race conditions during first-access initialization can create duplicate records; a distributed lock guarantees exactly-once creation.
Two-Layer Config Caching
Frequently read configurations are cached in Redis, and the API gateway additionally caches full response payloads for config endpoints.
Why: Two-layer caching (Redis + gateway) reduces config read latency to sub-millisecond for the most common queries.
Technical Decisions
| Technical Decisions | Chosen | Alternative | Reason |
|---|---|---|---|
| Config caching strategy | Redis cache + gateway response cache (two-layer) | Redis only | Gateway-level response caching eliminates Redis round trips entirely for high-frequency config reads that rarely change. |
| Feature flag storage | Database-backed with Redis cache | External feature flag service | Keeping flags in the existing MySQL/Redis stack avoids adding an external dependency. |