Multi-tenant

One installation, many books, isolated by design.

One deployment serves many tenants; a separate database is a separate deploymentOne deployment over one database holding four tenants, each record carrying its tenant; beside it a separate deployment with its own database for a bank that wants one.One deploymentAPI · worker · day-endOne databaseTenant Astructured financeevery recordcarries its tenantTenant Bretail lendingevery recordcarries its tenantTenant Ca partner's customerevery recordcarries its tenantTenant Da partner's customerevery recordcarries its tenantSeparate deploymenta bank on its own floorIts own databaseTenant Eone bank, one book
A tenant is data. Creating one needs no schema change.

Every document and every event carries its tenant.

One database, one set of code, and the data layer discriminates every read and write by tenant. A tenant is data: creating one needs no schema change. A bank runs one tenant. A partner runs one installation with a tenant per customer. A bank that wants a database to itself gets a separate deployment, not a special case inside one.

What a partner sees
  1. Provision a tenant from a templateaccount types, capabilities, sample data
  2. Tune itsettings, rate cards, calendars, posting rules
  3. Switch on the capabilities the customer pays forthe manifest is the price list
  4. Run itday-end per tenant, books per operating entity, statements branded per entity

What this means for you: a second customer is a second tenant, not a second installation. Your cost to serve customer twenty is close to zero.