Configuration & Access-Control Service
Tenant configuration, domain management and a priority-based allow/deny engine
Overview
Platform and tenant configuration: domains, banners, versions, tenant settings and access rules. I wrote the first version, split it into its own service (42 RPCs at the split), and in 2025 rebuilt its access-control rules into a single engine.
Architecture
Gateway middleware → configuration gRPC service → rule engine (allowlist by account, nickname or IP takes priority; deny rules match on account, nickname, IP, IP location and bank card together) → per-tenant Redis hash → MySQL on a miss.
Key Highlights
Two legacy allow/deny lists consolidated into one priority-based engine with 5 match dimensions; it denies access when rules can't be loaded
Rules served from a per-tenant Redis hash with a TTL and a singleflight-protected database fallback
Existing rules migrated into the new table with a one-off SQL migration (CSV → JSON arrays)
Tenant domain management: link verification, uniqueness checks backed by a Redis set, and a manual cache re-sync
Banner targeting by content category with Kafka change events to connected clients
Key Implementations
Unified rule engine
One rule table with action and priority, normalised and evaluated in memory per request, returning which dimensions matched for logging.
Why: Two separate lists with separate code paths disagreed in edge cases; one engine with explicit priority is easier to reason about and to audit.
Technical Decisions
| Technical Decisions | Chosen | Alternative | Reason |
|---|---|---|---|
| Rule cache layout | One Redis hash per tenant, evaluated in memory | One Redis key per dimension value | Rule sets per tenant are small; one fetch per tenant is simpler and avoids keeping many index keys consistent. |