Hacker News Reader

Comment by Geee | Hacker News Reader

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.

View on HN

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.

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.

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?

You shard for load distribution. If data isolation is #1 priority, use separate tables, schemas, database instances.

Separate disks, separate machines hell even separate networks, proper data isolation can be super expensive to do right.

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.

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).

Reply on news.ycombinator.com