zevOS

01Technology

Multi-tenancy in a charging platform, and where isolation actually fails

Every serious charging platform serves several operators. The boundary between them has to be enforced in one place, not remembered in every query.

ENzevOS Engineering · Platform engineering
7 October 2025 · 2 min read

A platform serving multiple charging operators holds several businesses’ money, drivers and infrastructure in one system. Isolation between them is not a feature — it is the precondition for the product existing. And it fails in a consistent, boring way: somebody writes a query and forgets the filter.

Do not rely on remembering

The pattern that works is that tenant scoping is applied in one layer that every data access passes through, rather than being a clause each developer adds. Where that layer exists, a forgotten filter is impossible. Where it does not, correctness depends on every query ever written, including the one added under time pressure on a Friday.

  • Every tenant-scoped table carries a tenant identifier, indexed, non-null.
  • The repository layer applies the filter automatically from request context — not from a parameter the caller passes, which can be wrong.
  • Platform-level tables that legitimately span tenants are a small, explicitly enumerated list, and access to them is a separate code path.
  • Any query that bypasses the layer is a review finding, not a shortcut.

The four places it actually leaks

LeakWhy it happens
Aggregate and reporting queriesWritten as raw SQL for performance, bypassing the layer
Background jobsNo request context, so the tenant has to be threaded through manually
Lookup by opaque idA UUID looks unguessable, so the filter feels redundant. It is not
CachesA cache key without the tenant serves one operator another’s data

The third row is the most common in practice and the most dangerous, because it is invisible until someone enumerates identifiers. An object fetched by id must still be checked against the caller’s tenant, however unguessable the id looks.

Isolation within a tenant

The second boundary matters almost as much. Inside one operator, staff should see only the stations they are responsible for, partners should see only their own sites, and financial actions — refunds, settlement approval, tariff changes — should be permissioned separately from day-to-day operations.

That is not paranoia about employees. It is that a support agent with the ability to issue unlimited refunds is a control failure an auditor will find, and a partner who can see another partner’s revenue is a commercial incident.

Proving it

Isolation claims are cheap. The demonstrations that mean something are a test suite that asserts cross-tenant access returns nothing, an audit trail that records who read and changed what, and a willingness to show both during an evaluation. Ask any platform for them, including this one.

architecturesecurityscale

Get the next one by email

One email a month. Operations notes, unit economics and policy changes that affect your tariff.