Quando Elasticsearch é inadequado como banco de dados principal?

Question

IT Interview Practice · Accepted Answer

Elasticsearch pode armazenar dados de forma durável. Para decidir se deve ser o banco principal, pergunte **quais regras de negócio precisam permanecer verdadeiras quando escritas falham ou ocorrem simultaneamente**.

Em um sistema de pedidos, encontrar produtos e confirmar uma compra são tarefas diferentes. A primeira precisa de relevância na busca; a segunda, de alterações corretas em pagamentos e estoque.

## 1. Comece pelas alterações que devem ter sucesso juntas

Suponha que uma compra exija registrar o pedido e reduzir o estoque. O negócio deve definir o que acontece se apenas uma operação funcionar.

```text
[Create order] ---- must coordinate ---- [Reduce stock]
      |                                      |
   success                                failure?
```

A bulk API envia várias operações de documentos juntas, mas uma pode falhar enquanto outra tem sucesso. Isso não as transforma em uma transação de tudo ou nada. A aplicação precisa examinar cada resultado. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Se o requisito é uma alteração atômica entre registros, um banco transacional costuma oferecer uma base mais direta. Implementar essa coordenação por conta própria acrescenta cenários de falha e recuperação.

## 2. Diferencie proteção do documento de garantias de negócio

O controle otimista de concorrência verifica se o documento não mudou desde a versão lida. Ele pode rejeitar uma atualização desatualizada e impedir que um cliente sobrescreva silenciosamente o trabalho de outro. [Controle de concorrência](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Essa proteção vale para o documento atualizado. Ela não coordena automaticamente estoque e pedido, não fornece chaves estrangeiras relacionais nem aplica regras arbitrárias de unicidade entre campos de negócio.

Anote as regras exigidas pela aplicação antes de escolher o armazenamento. Isso torna a decisão concreta, sem depender do rótulo “mecanismo de busca” ou “banco de dados”.

## 3. Verifique quando uma escrita fica pesquisável

Uma escrita bem-sucedida e um resultado visível na busca são eventos separados:

```text
[Write accepted] -> [Refresh] -> [Search can see the change]
```

O refresh torna alterações recentes visíveis na busca. Por isso, uma leitura em tempo real pelo ID difere de uma consulta de busca. A opção refresh=wait_for pode esperar a visibilidade, mas não cria uma transação entre documentos. [Comportamento do refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Uma pequena demora pode ser aceitável na busca de produtos. Para decidir um pagamento final ou uma permissão, defina explicitamente a consistência necessária e leia uma fonte que a forneça. Refresh e armazenamento durável também são preocupações distintas.

## 4. Escolha o papel do Elasticsearch

| Requisito | Direção a avaliar | Motivo |
| --- | --- | --- |
| Pedidos e registros relacionados devem mudar atomicamente | Banco principal transacional | As regras de correção devem ficar próximas dos registros oficiais. |
| Usuários precisam de busca textual flexível | Elasticsearch como cópia de busca | Os dados de busca podem ser modelados e reconstruídos separadamente. |
| Documentos independentes com consistência compatível | Elasticsearch pode servir como armazenamento principal | Um segundo banco deve ter finalidade demonstrada. |

Um desenho comum para pedidos é:

```text
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
 authoritative data                               search copy
```

CDC captura alterações confirmadas; uma outbox registra um evento junto da atualização de negócio na mesma transação. Outro processo entrega as alterações ao índice. Assim, não dependemos de duas escritas independentes sempre terem sucesso juntas.

A indexação ainda precisa de IDs estáveis, versões, exclusões, retries e monitoramento do atraso. Teste reconstruir o índice a partir da origem. Caso contrário, a cópia de busca pode virar uma segunda fonte de verdade inconsistente.

## 5. Confirme o modelo de recuperação antes da escolha

Seja qual for o papel, planeje backups e teste restaurações. Réplicas ajudam a disponibilidade, mas não substituem backups. Defina perda aceitável de dados e tempo de recuperação para a configuração real.

No exemplo de pedidos, eu manteria os registros transacionais em um banco que suporte suas regras e adicionaria Elasticsearch se a busca justificasse. Para documentos independentes voltados à pesquisa, avaliaria se ele sozinho atende armazenamento, consistência e recuperação.

**Lembre-se:** escolha pelas garantias necessárias e verifique falhas e recuperação. A velocidade da busca é apenas parte da decisão.

Requisito	Direção a avaliar	Motivo
Pedidos e registros relacionados devem mudar atomicamente	Banco principal transacional	As regras de correção devem ficar próximas dos registros oficiais.
Usuários precisam de busca textual flexível	Elasticsearch como cópia de busca	Os dados de busca podem ser modelados e reconstruídos separadamente.
Documentos independentes com consistência compatível	Elasticsearch pode servir como armazenamento principal	Um segundo banco deve ter finalidade demonstrada.

1. Comece pelas alterações que devem ter sucesso juntas

2. Diferencie proteção do documento de garantias de negócio

3. Verifique quando uma escrita fica pesquisável

4. Escolha o papel do Elasticsearch

5. Confirme o modelo de recuperação antes da escolha

Perguntas relacionadas