Elasticsearch: consistência de leitura e gravação

O Elasticsearch não possui parâmetros de "consistência de leitura" (como Cassandra). Mas tem "escrever consistência"e"ler preferência"

A documentação diz o seguinte sobreConsistência de gravação

Consistência de gravação
Para impedir que gravações ocorram no lado "errado" de uma partição de rede, por padrão, as operações de índice só serão bem-sucedidas se um quorum (> réplicas / 2 + 1) de shards ativos estiver disponível. Esse padrão pode ser substituído em uma base por nó, usando a configuração action.write_consistency. Para alterar esse comportamento por operação, o parâmetro de solicitação de consistência pode ser usado.

Os valores válidos da consistência de gravação são um, quorum e todos.

Observe que, no caso em que o número de réplicas seja 1 (total de 2 cópias dos dados), o comportamento padrão será bem-sucedido se 1 cópia (a primária) puder executar a gravação.

A operação de índice retorna apenas depois de tudoativo os shards dentro do grupo de replicação indexaram o documento (replicação de sincronização).

Minha pergunta é sobre o último parágrafo:

A operação de índice retorna apenas depois de tudoativo os shards dentro do grupo de replicação indexaram o documento (replicação de sincronização).

E sewrite_consistency=quorum (padrão) e todos os shards estão ativos (sem falhas de nó, sem partição de rede), então:
1) A operação de índice retorna assim quequorum de shards terminou a indexação? (mesmo que todos os shards estejam ativos / ativos)
2) Ou a operação de índice retorna quandotodos os shards ativos / ativos concluíram a indexação? (ou seja, o quorum é considerado apenas em caso de falhas / tempos limite)

No primeiro caso - a leitura pode ser eventualmente consistente (pode obter dados obsoletos), a gravação é mais rápida.
No segundo caso - a leitura é consistente (desde que não haja partições de rede), a gravação é mais lenta (enquanto aguarda o shard / nó mais lento).

Alguém sabe como isso funciona?

Outra coisa que me pergunto é por que o valor padrão de "preferência'param (na solicitação de obtenção / pesquisa) érandomized mas não_local (que deve ter sido mais eficiente, suponho)