A platform serving several operators has to keep them apart convincingly while sharing enough infrastructure to be economic. Where that line sits is the defining architectural decision, and it is difficult to move later.
Getting it wrong in the permissive direction produces a data exposure. Getting it wrong in the restrictive direction produces a platform too expensive to operate.
Boundaries that must be absolute
The test is not whether the interface prevents access. It is whether a query with a missing filter could return another tenant's data, because eventually one will be written.
- Session and transaction data, which is commercially sensitive.
- Driver and customer records, which carry privacy obligations.
- Tariffs and commercial terms, which competitors must not see.
- Charger inventory and location data where it is not public.
- Anything a tenant can export, which must never contain another tenant's rows.
Enforce isolation below the application
Isolation that depends on every query including a tenant condition will fail, because it depends on every developer remembering. Enforcement at the data layer, so a query without a tenant context returns nothing rather than everything, is what survives.
This is more work initially and it is the difference between a boundary and a convention.
What can safely be shared
Protocol handling, connection management, firmware artefacts, reference data and the operational infrastructure. None of these carry tenant-specific information, and sharing them is where the economics of multi-tenancy come from.
Charger connections themselves are shared infrastructure with a tenant attribute, which is why charger onboarding has to establish tenancy before any data is recorded.
Noisy neighbours
One tenant with a large fleet, an aggressive reporting habit or a misbehaving integration can degrade service for everyone. Rate limiting and resource accounting per tenant are not optional at any meaningful scale.
The failure without them is that a small tenant experiences an outage caused entirely by someone they have never heard of, and your support team cannot explain it.
Configuration divergence
Tenants will want different tariff structures, authorisation rules, branding and workflows. Configuration handles that; code branches per tenant do not, and a platform that has accumulated them is no longer one platform.
The discipline is to express differences as configuration or to decline them, rather than to special-case. That is a commercial discipline as much as a technical one.
Exit has to work per tenant
A tenant leaving must be able to take their data and repoint their chargers without affecting anyone else, and their records must be removable without disturbing shared structures.
Designing this at the start is straightforward. Retrofitting it into a platform where tenant data is entangled is a project, and it typically becomes urgent at the worst moment.