3 ms·

Why is the shared app & shared database the most complex beast? Technically it's the simplest and requires the least amount of work to set up and maintain. You

by Geee 6y ago

Why is the shared app & shared database the most complex beast? Technically it's the simplest and requires the least amount of work to set up and maintain. You can even run the app & db on the same server. The complexity of maintaining multiple app & db instances isn't worth it, at least when you're starting out.

deleted 6y ago
[deleted]
laluser 6y ago
Everything is simple when you're starting out. Over time, you'd see that users can have wildly different load patterns, which will affect how you scale and shard your database over time. It's a huge pain to manage and grow.
- zepolen 6y ago
  It's way easier to scale a shared app/db, anyone who tells you different hasn't had to do devops. Rule No. 1, never shard by account_id, Pareto is just waiting you kick you in the ass. Always shard by whatever gives the best distribution of workload. There are more rules of course.
  - sb8244 6y ago
    I've always considered data isolation as the #1 priority when it comes to tenancy. Does that mean that the sharding should defacto be done on the tenant ID?
    - pietherr 6y ago
      You shard for load distribution. If data isolation is #1 priority, use separate tables, schemas, database instances.
      - zepolen 6y ago
        Separate disks, separate machines hell even separate networks, proper data isolation can be super expensive to do right.
jeffffff 6y ago
at a certain scale you have to assume that at any given time at least one of your users is guaranteed to be doing something dumb that will cause performance issues. if you haven't implemented rate limiting or request prioritization at every layer of your system in a fully shared environment this will break everything for everyone instead of just breaking it for the one bad actor. having fewer shared components means having fewer ways for this to go wrong. even multiple app instances and multiple db instances on the same machine isn't necessarily enough if you don't do proper isolation with containers or vms due to noisy neighbor issues. and don't even think about sending requests from different users to the same hdd because there is almost no way to isolate them appropriately, ssds make this so much easier.
bri3d 6y ago
It's the least flexible strategy _because_ it's the simplest - as soon as a customer comes knocking requiring data isolation, you have a hard business decision to make. It's also a lot harder to extract / deal with a business critical "hot" customer in either direction (either a very performance sensitive customer key to revenue, who could really use their own hardware, or a very bad customer with outsized resource consumption).

by Geee 6y ago

deleted 6y ago

[deleted]

laluser 6y ago

Everything is simple when you're starting out. Over time, you'd see that users can have wildly different load patterns, which will affect how you scale and shard your database over time. It's a huge pain to manage and grow.

zepolen 6y ago
It's way easier to scale a shared app/db, anyone who tells you different hasn't had to do devops. Rule No. 1, never shard by account_id, Pareto is just waiting you kick you in the ass. Always shard by whatever gives the best distribution of workload. There are more rules of course.
- sb8244 6y ago
  I've always considered data isolation as the #1 priority when it comes to tenancy. Does that mean that the sharding should defacto be done on the tenant ID?
  - pietherr 6y ago
    You shard for load distribution. If data isolation is #1 priority, use separate tables, schemas, database instances.
    - zepolen 6y ago
      Separate disks, separate machines hell even separate networks, proper data isolation can be super expensive to do right.

jeffffff 6y ago

at a certain scale you have to assume that at any given time at least one of your users is guaranteed to be doing something dumb that will cause performance issues. if you haven't implemented rate limiting or request prioritization at every layer of your system in a fully shared environment this will break everything for everyone instead of just breaking it for the one bad actor. having fewer shared components means having fewer ways for this to go wrong. even multiple app instances and multiple db instances on the same machine isn't necessarily enough if you don't do proper isolation with containers or vms due to noisy neighbor issues. and don't even think about sending requests from different users to the same hdd because there is almost no way to isolate them appropriately, ssds make this so much easier.

bri3d 6y ago

It's the least flexible strategy _because_ it's the simplest - as soon as a customer comes knocking requiring data isolation, you have a hard business decision to make. It's also a lot harder to extract / deal with a business critical "hot" customer in either direction (either a very performance sensitive customer key to revenue, who could really use their own hardware, or a very bad customer with outsized resource consumption).