Lesson 18.918.9 What a tenant is

Part C is the heart of the chapter: one connector serving many companies. It covers who may act for which company. Chapter 19 covers the other half: whose rows are whose in the database.

In everyday life. An apartment building has one front door, one elevator and one set of pipes, but each apartment has its own lock, its own mailbox and its own lease. The manager must never hand one family's mail to another, however busy the lobby gets. Landlords build for many families in three ways. One big building, where everyone shares the front door and the apartment lock does the work. A row of townhouses, each with its own front door on its own street number. Or a whole separate house for one large family.

What you will learn. What it means to keep customer companies apart on one connector, and the three ways to build for that.

Why it matters. Each request must be answered for its own company, whatever anyone types. How you build decides how firmly the companies are kept apart.

One request, start to finish. Cedar Ridge Supply becomes the connector's second customer. On Monday morning two requests reach the same copy of the connector in the same second:

1. Ana's, for Brightline: "Which invoices are due this week?"
2. Luis's, for Cedar Ridge: the same question.

The connector must answer each for its own company, and nothing either person does or types may change which company they get.

What is a tenant?

A tenant is one customer company whose people and data must be kept apart from every other's. The word comes from renting: many tenants, one building. Brightline and Cedar Ridge are two tenants. A membership links one person to one tenant, with a role. It is the member table from 18.8. One person can have memberships in two tenants, like Priya.

How a system is built to serve many tenants is its tenancy model. The three models match the three kinds of housing. In one line each:

1. One shared connector: one address for everyone. The token says which company.
2. One address per company: the same code at several addresses, and each token works at one address only.
3. One deployment per company: a whole separate copy for one large customer.

The table compares them:

When do you move a company up?

Start every company in the first model. Move one to the second when it asks for its own address, or its contract asks for that second wall. Move one to the third when it needs its own update schedule, its own keys, its data kept in a particular country, or so much traffic that it would slow everyone else. The connector's code is the same in all three models. Only two things change: where it runs, and which address its tokens are made for. Because the company always comes from the token (18.10), the same rule works in every model.

Which model does Brightline use?

Brightline uses the first model. It has two small customers and expects more of the same size. The seven rules in 18.11 and 18.12 make the claim trustworthy, and the tests in 18.13 prove it on every build.

What are the two halves of keeping companies apart?

1. Who may act for which company: sign-in, consent, the company in the token, and the connector refusing anything else. This chapter.
2. Whose data is whose: each company's rows kept apart in the database, even when code forgets. Chapter 19.

At work. The builder writes in docs/auth-spec.md: "Model 1, one shared connector. Company from the token only. Model 2 on request. Model 3 only by contract." Later, a large hospital chain asks Brightline for the connector. The builder notes that it would be model 3: its own deployment, keys and data.

The operating rule: name your tenancy model before you build, and start with one shared connector that takes the company from the token. Move a company to its own address or its own deployment only for a reason you can write down.

What Chapter 19 adds: each company's business data in a database that refuses to return another company's rows.

Figure 18.12. Three tenancy models. Brightline starts with the first and can move a company to the second or third.