Guide: architecting a multi-tenant B2B platform

A B2B platform serves several client companies at once, each with its own users, data and rules. The decisions made in the first weeks, about client isolation, roles or how money is counted, are the ones that cost the most to change later. This guide sums up the choices we make, and why, on the business banking, payment and management platforms we build.

Three questions before choosing an architecture

1. Where is the responsibility boundary between clients? A company must never see another company's data, even in case of a bug. That is the starting point, not an option.
2. Which rules must never be broken? A balance that cannot go negative without authorization, an invoice that no longer changes once issued, an operation executed only once.
3. Who will operate the platform? A small team needs a system that is simple to deploy and observe; sophistication is paid for every day in operations.

Modular monolith or microservices

Both work, provided they are modular. A monolith properly split into modules, with clear boundaries and a single database, remains the most economical choice to start. Microservices become relevant when parts of the system evolve at different paces, need different resources or must be isolated for security (for example, everything that touches payments).

• Advantages of the modular monolith: one deployment, simple transactions, direct debugging.
• Advantages of microservices: fault isolation, targeted scaling, autonomous teams.
• Shared cost: without explicit boundaries between modules, both end up tangled. Writing the contracts between modules, testing those contracts, and keeping a single gateway on the client side are the real guardrails.

Multi-tenancy: isolating without duplicating

Three models exist to separate clients' data:

• One database per client: maximum isolation, high operating cost, migrations repeated as many times as there are clients.
• One schema per client in the same database: a good compromise for a few dozen clients, more fragile beyond.
• One row per client, with a tenant identifier on every record: the most common, provided the identifier is enforced by the foundation and never left to each query.

Whatever the model, the current tenant must come from authentication, be propagated automatically to every data access, and be covered by a test that deliberately tries to read another client's data.

Access control: roles, permissions, log

Role-based access control (RBAC) remains the most readable for business users: a role groups permissions, a user receives roles per company. Data-dependent rules (a manager only approves their own team's expenses) are expressed as conditions added to permissions, without switching to an attribute system that is hard to audit.

• Permissions are checked server-side, in a single place, never only in the interface.
• Every sensitive action is logged with the author, the tenant, the object and the before/after.
• Internal operations roles (support, administration) are distinct from client roles and subject to the same log.

Money and invariants

When the platform handles money, three rules avoid most accidents: represent amounts as integers (cents) and never as floating-point numbers; keep a double-entry ledger, where every movement has a counterpart and the balance is derived from entries rather than modified directly; make every operation idempotent, with a key supplied by the caller, so that a network retry does not execute it twice.

Observability and operations

• Structured logs, with the request identifier and the tenant, correlated across services.
• Health indicators per service and an internal status page.
• Reference data loaded at boot and versioned, for reproducible environments.
• A single installation script that brings up a complete environment in a few minutes: it is the best test of the system's simplicity.

Checklist

• Isolation between clients is enforced by the foundation and covered by a negative test.
• Business invariants are written and verified by tests before any new feature.
• Permissions are centralized server-side and logged.
• Amounts are integers, the ledger is double-entry, operations are idempotent.
• A complete environment starts with one command.
• Boundaries between modules or services are documented and tested.
• An end-to-end simulation (from the first user to the first invoice) is replayed at every release.

Conclusion

A B2B platform stands on its invisible rules. Fixing them first then makes it possible to add modules quickly and without fear. It is the approach we followed on the SIIC platform, and that we offer in our custom development. To talk about your architecture, contact us.