3 ms·
> Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team copies of Eric Evans and ask them to design data schema and sharding sche
by balfirevic 6y ago
> Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team copies of Eric Evans and ask them to design data schema and sharding scheme such that any given entity has a bounded context that doesn’t join across the network.
That will only help you scale out to N servers, where N is the number of bounded contexts. And it might end up being less helpful than it sounds, if the scaling needs are dominated by data in one or two bounded contexts.
Still, it could be a useful approach.
- inopinatus 6y agoNo, the dimension is in the other axis. Otherwise there’d be no need for sharding keys.
- balfirevic 6y agoBut if you have nice natural sharding keys for your data (the most common example is something like TenantId), how do bounded contexts help? EDIT: Perhaps you mean something different by bounded context than what is usually meant in the context of DDD, where they separate groups of entities not data within those entities.
- inopinatus 6y agoNo, I mean exactly that, but tenant_id sounds like a SaaS or a Shopify. Their pods don’t have this kind of scale to begin with, the datasets just don’t have more than a few billion entities. Assuming there’s a “nice natural sharding key” at all already limits scope to a subset of applications, most of which you can stick inside a single instance, rendering the point moot.