2 ms·

sending another customer's data to the wrong customer.

hansvm 3y ago
One company I worked at literally gave every customer (high-touch B2B, not an untenable customer count) their own database to reduce that risk and serve as a crude sharding strategy for horizontal scaling.
- topspin 3y ago
  That is a legitimate strategy. It's being done in many products, often with SQLite or similar embedded databases, synchronized between devices and backend systems. It has the wonderful property that some fault of one database does not impact others. I recall some major GitHub outages not too long ago and learning that they'd built the system on one globe-spanning distributed MySQL database, that fell over a couple times. A GitHub designed around separate databases for projects wouldn't have that failure mode. Obviously that would create problems on the backend for aggregation, billing, etc., but those are mostly "you" problems, as opposed to the "me" problem when you topple the monster database and take away my repos. They've since had to isolate problem children to separate databases, away from the hoi polloi in the big "primary" database[1]. So I suppose I wasn't wrong. https://github.blog/2023-12-07-upgrading-github-com-to-mysql-8-0/ https://github.blog/2023-12-07-upgrading-github-com-to-mysql...
  - hansvm 3y ago
    > That is a legitimate strategy Yeah, definitely. Sorry if my post came across as saying anything else. The word "crude" simply referred to the facts that it's not complicated (which is good, one of the technique's strong suites tbh), and it's not complicated in a way that throws away parameters you might actually care about and which a more advanced strategy could consider (e.g., if you have one really big customer then you have to amend the sharding strategy). It introduced its own set of costs (those "you" problems you mentioned, like aggregation and billing), but I think it was the right choice.

One company I worked at literally gave every customer (high-touch B2B, not an untenable customer count) their own database to reduce that risk and serve as a crude sharding strategy for horizontal scaling.

topspin 3y ago
That is a legitimate strategy. It's being done in many products, often with SQLite or similar embedded databases, synchronized between devices and backend systems. It has the wonderful property that some fault of one database does not impact others. I recall some major GitHub outages not too long ago and learning that they'd built the system on one globe-spanning distributed MySQL database, that fell over a couple times. A GitHub designed around separate databases for projects wouldn't have that failure mode. Obviously that would create problems on the backend for aggregation, billing, etc., but those are mostly "you" problems, as opposed to the "me" problem when you topple the monster database and take away my repos. They've since had to isolate problem children to separate databases, away from the hoi polloi in the big "primary" database[1]. So I suppose I wasn't wrong. https://github.blog/2023-12-07-upgrading-github-com-to-mysql-8-0/ https://github.blog/2023-12-07-upgrading-github-com-to-mysql...
- hansvm 3y ago
  > That is a legitimate strategy Yeah, definitely. Sorry if my post came across as saying anything else. The word "crude" simply referred to the facts that it's not complicated (which is good, one of the technique's strong suites tbh), and it's not complicated in a way that throws away parameters you might actually care about and which a more advanced strategy could consider (e.g., if you have one really big customer then you have to amend the sharding strategy). It introduced its own set of costs (those "you" problems you mentioned, like aggregation and billing), but I think it was the right choice.