[Rickasaurus]

Recently was looking at a distributed microservice system at a company that thought they would need massive scale, but pivoted from d2c to enterprise b2b and then found out enterprise b2b companies want data separation. They would have been much better off going monolith first and probably actually sticking with a monolith.

[kgeist]

You mean it's easier to shard databases per tenant when it's a monolith?

[crmd]

Data separation in enterprise-land means customers don’t want components that touch their data to be shared with any other customers. So a shared but sharded database is no good. In practice you often run a standalone stack for each customer, including their own database. This pattern is a nightmare from an operational scaling perspective, but that’s part of why enterprises are asked to pay so much.

[kgeist]

I understand what it means, I'd like to know where the monolith architecture stands in this context. One of our projects was originally a monolith, and each tenant had their own dedicated DB the monolith connected to. Then they switched to the microservice architecture (back when it was the peak of the hype) and rejected the idea of database sharding because each microservice already requires their own DB, and if you also sharded by tenant, then you'd end up with M x N databases (where M is the number of tenants and N is the number of microservices) which sounds like a lot of complexity to manage. I think they once had a bug where one tenant could see data from another tenant because they don't have strong DB boundaries anymore.