Quand Elasticsearch est-il mal adapté comme base principale ?

Question

IT Interview Practice · Accepted Answer

Elasticsearch peut conserver durablement des données. Pour le choisir comme base principale, demandez **quelles règles métier doivent rester vraies lorsque les écritures échouent ou se concurrencent**.

Chercher un produit et confirmer un achat sont deux tâches. La première privilégie la pertinence ; la seconde exige des paiements et stocks corrects.

## 1. Partir des changements qui doivent réussir ensemble

Un achat nécessite par exemple une commande et une diminution du stock. Le métier doit définir le cas où une seule réussit.

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

L’API bulk soumet plusieurs opérations ensemble, mais une peut échouer indépendamment des autres. Elle ne crée pas une transaction tout ou rien. L’application doit examiner chaque résultat. [API Bulk](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Pour modifier atomiquement plusieurs enregistrements, une base transactionnelle offre généralement un fondement plus direct. Construire cette coordination ajoute des pannes et de la récupération à gérer.

## 2. Distinguer protection documentaire et garanties métier

Le contrôle optimiste vérifie que le document n’a pas changé depuis la version lue. Il peut rejeter une mise à jour périmée et éviter d’écraser silencieusement le travail d’un autre client. [Contrôle de concurrence](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Il protège le document concerné, sans coordonner automatiquement stock et commande, fournir des clés étrangères relationnelles ou imposer toute unicité métier entre champs.

Écrivez les règles nécessaires avant le choix du stockage. La décision devient concrète au lieu de dépendre des étiquettes « moteur de recherche » ou « base ».

## 3. Vérifier la visibilité des écritures

Une écriture réussie et un résultat visible sont deux événements :

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

Refresh rend les changements récents visibles aux recherches. Lire en temps réel par ID diffère donc d’une recherche. refresh=wait_for attend éventuellement cette visibilité, sans créer de transaction multidocument. [Comportement refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Un petit délai peut convenir à une recherche produit. Pour un paiement final ou une permission, précisez la cohérence et utilisez une source qui la fournit. Refresh et stockage durable sont aussi distincts.

## 4. Choisir le rôle d’Elasticsearch

| Besoin | Piste à évaluer | Raison |
| --- | --- | --- |
| Commande et données liées changent atomiquement | Base principale transactionnelle | Les règles se placent près des enregistrements autoritatifs. |
| Recherche plein texte flexible | Elasticsearch comme copie de recherche | Modélisation et reconstruction indépendantes. |
| Documents autonomes avec cohérence compatible | Peut convenir comme stockage principal | Une seconde base doit avoir une utilité démontrée. |

Une architecture courante est :

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

CDC capture les changements validés ; outbox enregistre un événement dans la transaction métier. Un autre processus les livre à l’index. Deux écritures indépendantes ne doivent donc plus réussir systématiquement ensemble.

L’indexation nécessite toujours IDs stables, versions, suppressions, reprises et suivi du retard. Testez la reconstruction depuis la source pour éviter une seconde vérité incohérente.

## 5. Confirmer la récupération

Prévoyez des sauvegardes et testez leur restauration quel que soit le rôle. Les répliques aident la disponibilité, sans remplacer les sauvegardes. Fixez perte acceptable et délai de reprise pour la configuration réelle.

Pour les commandes, je garderais les données transactionnelles dans une base adaptée et ajouterais Elasticsearch si la recherche le justifie. Pour des documents indépendants centrés sur la recherche, je vérifierais s’il suffit seul au stockage, à la cohérence et à la reprise.

**À retenir :** choisir les garanties nécessaires, puis vérifier pannes et restauration. La rapidité de recherche n’est qu’un critère.

Besoin	Piste à évaluer	Raison
Commande et données liées changent atomiquement	Base principale transactionnelle	Les règles se placent près des enregistrements autoritatifs.
Recherche plein texte flexible	Elasticsearch comme copie de recherche	Modélisation et reconstruction indépendantes.
Documents autonomes avec cohérence compatible	Peut convenir comme stockage principal	Une seconde base doit avoir une utilité démontrée.

1. Partir des changements qui doivent réussir ensemble

2. Distinguer protection documentaire et garanties métier

3. Vérifier la visibilité des écritures

4. Choisir le rôle d’Elasticsearch

5. Confirmer la récupération

Questions connexes