The parent-child relationship can extend across more than one generation—grandchildren can have grandparents—but it requires an extra step to ensure
that documents from all generations are indexed on the same shard.

Let’s change our previous example to make the country type a parent of the
branch type:

The parent ID has ensured that each branch document is routed to the same
shard as its parent country document. However, look what would happen if we
were to use the same technique with the employee grandchildren:

The shard routing of the employee document would be decided by the parent ID—london—but the london document was routed to a shard by its own
parent ID—uk. It is very likely that the grandchild would end up on
a different shard from its parent and grandparent, which would prevent the
same-shard parent-child mapping from functioning.

Instead, we need to add an extra routing parameter, set to the ID of the
grandparent, to ensure that all three generations are indexed on the same
shard. The indexing request should look like this:

The parent parameter is still used to link the employee document with its
parent, but the routing parameter ensures that it is stored on the same
shard as its parent and grandparent. The routing value needs to be provided
for all single-document requests.

Querying and aggregating across generations works, as long as you step through
each generation. For instance, to find countries where employees enjoy hiking,
we need to join countries with branches, and branches with employees: