Hey friends, So my reasoning is::::
1. Use the same `val1!val2` routing 2. Push all `val1!` to same shard 3. When doing split shard, if most values are for `val1!`, (a very big tenant) then convert the shard to a child_index(same schema/settings as parent), and add an alias (so hash(`val1!)` points to this new child index) and actually split this new index but route internally only by `val1! *val2*`. 4. So when you query by _route_=val1, you get pointed to this child index that can have many shards. 5. While this will limit at first the write-speed to 1 shard, if we know the tenant_id in advance, we can do a covert of the shard to a child-index and pre-split it to several shards and balance them. This way you can have very big tenants and splitting the child indexes as much as you want. Makes sense as an idea ? Regards. Dorian
