Lead Software Engineer at RunMyBusiness, a Commercial Real Estate consultancy ▸ Attendee of every US Laracon ▸ Creator of ZoneWatcher, a DNS changelog service ▸ Follow on Twitter @tomschlick
you need it? ▸ Single Database vs Multi Database setups ▸ Segmenting the Job Queue, Console commands, Search, etc ▸ Dealing with external services ▸ Examples for getting started and popular packages
clause on every database query ▸ Using third party packages often requires modification to add the "tenant_id" field to both models & migrations ▸ Hard to scale database across multiple servers without a sharding plan set at the beginning ▸ Painful to export all of a specific customer's data
tenant ▸ Each tenant has a full copy of the application in their own database including migrations id name 1 Walter 2 Skyler TENANT 1: USERS id name 1 Jesse TENANT 2: USERS id name 1 Hector TENANT 3: USERS
connecting the current domain to the proper tenant database id subdomain name 1 hooli Hooli 2 initech Initech 3 umbrellacorp Umbrella Corp TENANTS TABLE
where data is segmented. Easy to test. ▸ Set it and forget it. No query scopes or WHERE clauses required. ▸ Less chance of Customer A's private data being shown to Customer B.
can easily be transitioned between servers depending on size, load, or failure ▸ Instead of scaling vertically by creating larger database servers, you can scale horizontally by creating more small sized servers
export, without complex separation steps ▸ Backups can be done separately per tenant, making them easier to restore ▸ Enterprise customers can be transitioned to on-premise setups easily ▸ Tenant data can be easily deleted at the request of the owner
done gradually, keeping the majority of customers online at once ▸ Choose where to store a customer's data based on their location, for reduced latency ▸ Customers can be added to "beta clusters" which get features before the general pool
display information from multiple tenants on the same page? 2. Do you need the option to segment, export, or privately host data for particular customers? 3. Do you plan to use a lot of third party packages? 4. Are your customers providing highly sensitive data to your application?
the same way you do for multi database setups by storing each file in a folder with the tenant's id ▸ Makes it easy to backup, move, and delete those files if the time comes
with either Singe or Multi Database setups ▸ Custom branding for your customers ▸ Allows customers to be logged into multiple accounts at once as each subdomain has their own sessions ▸ Allows you to use DNS to choose which servers handle requests per client
a wildcard SSL certificate to setup which can be costly (until LetsEncrypt offers them in Jan 2018) ▸ Your api has to live on the same domain, which can make it more complicated to funnel traffic to separate api servers ▸ Customers going to YOURAPP.COM directly would have to know which tenant they are a part of to get redirected to their own login page (similar to Slack's login)
you to serve different domains with separate SSL certificates ▸ Your customer controls the DNS which limits your ability to make changes for infrastructure reasons #2: THE CUSTOM DOMAIN : CONS HTTPS://YOURAPP.ACME.COM
into multiple accounts at once isn't available out of the box ▸ No easy way to specify which server gets the traffic from a specific customer without some type of middleman load balancer