Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Put the tenant discriminator in the key when you consolidate separate backends into one
When each tenant had its own server, tenant-agnostic keys could not collide - separation was structural. Merging onto one shared instance makes that safety purely a deployment detail, so one tenant can serve another's data. Encode the tenant in the key prefix so it is safe by construction.
Bad example
| 1 | // Previously: tenant A -> a-cache:11211, tenant B -> b-cache:11211 |
| 2 | // Now both use REDIS_HOST with the same literal prefix: |
| 3 | const prefix = "service:"; |
| 4 | const key = `${prefix}${moduleName}_Module`; // no tenant component |
Explanation (EN)
Nothing in the key distinguishes tenants, so the only thing preventing cross-tenant reads is that the two deployments happen to point at different hosts.
Objašnjenje (HR)
Nista u kljucu ne razlikuje najmoprimce, pa jedino sto sprjecava citanje tudih podataka jest to sto dvije instalacije slucajno gadaju razlicite posluzitelje.
Good example
| 1 | const prefix = `service:${AppConfig.publicationName}:`; |
| 2 | const key = `${prefix}${moduleName}_Module`; |
Explanation (EN)
Collisions are impossible regardless of how the instances are deployed, and pointing two tenants at one instance stops being a risk.
Objašnjenje (HR)
Sudari su nemoguci bez obzira na to kako su instance postavljene, pa usmjeravanje dvaju najmoprimaca na jednu instancu prestaje biti rizik.
Notes (EN)
The moment to add this is the migration itself. Afterwards the collision is invisible in code review because every individual key still looks fine.
Bilješke (HR)
Trenutak za to je sama migracija. Poslije je sudar nevidljiv u pregledu koda jer svaki pojedinacni kljuc i dalje izgleda ispravno.