Elasticsearch puede almacenar datos de forma duradera. Para elegirlo como base principal, pregunta qué reglas deben mantenerse cuando las escrituras fallan o coinciden.
Buscar productos y confirmar compras son tareas distintas. La primera prioriza relevancia; la segunda, cambios correctos en pagos e inventario.
Una compra puede requerir crear un pedido y reducir existencias. El negocio debe definir qué sucede si solo una operación tiene éxito.
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
La API bulk envía varias operaciones juntas, pero una puede fallar y otra funcionar. No crea una transacción de todo o nada. La aplicación debe inspeccionar cada resultado. Bulk API.
Para cambios atómicos entre registros, una base transaccional suele dar una solución más directa. Construir esa coordinación añade fallos y recuperación propios.
El control optimista verifica que el documento no haya cambiado desde la versión leída. Puede rechazar una actualización antigua y evitar sobrescribir silenciosamente el trabajo de otro cliente. Control de concurrencia.
Protege ese documento, pero no coordina automáticamente existencias y pedido, ni proporciona claves foráneas relacionales o unicidad arbitraria entre campos de negocio.
Escribe las reglas necesarias antes de elegir almacenamiento. Así decides con requisitos concretos, no con las etiquetas «buscador» o «base de datos».
Una escritura exitosa y un resultado visible son eventos distintos:
[Write accepted] -> [Refresh] -> [Search can see the change]
Refresh hace visibles los cambios recientes. Por eso una lectura en tiempo real por ID difiere de una búsqueda. refresh=wait_for puede esperar visibilidad, pero no crea una transacción multidocumento. Comportamiento de refresh.
Una demora breve puede servir para buscar productos. Para pagos finales o permisos, define la consistencia y lee una fuente que la garantice. Refresh y almacenamiento duradero también son asuntos diferentes.
| Requisito | Dirección que evaluar | Motivo |
|---|---|---|
| Pedidos y registros relacionados deben cambiar atómicamente | Base principal transaccional | Las reglas pertenecen junto a los registros autoritativos. |
| Búsqueda flexible de texto completo | Elasticsearch como copia de búsqueda | Puede modelarse y reconstruirse independientemente. |
| Documentos independientes con consistencia compatible | Puede encajar como almacén principal | Una segunda base necesita un propósito demostrado. |
Un diseño común de pedidos es:
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
CDC captura cambios confirmados; outbox registra un evento junto con la actualización en la misma transacción. Otro proceso lo entrega al índice. Así no dependes de dos escrituras independientes que siempre deban tener éxito juntas.
La indexación necesita IDs estables, versiones, borrados, reintentos y vigilancia del retraso. Prueba reconstruir desde el origen; de otro modo, la copia puede convertirse en otra fuente de verdad inconsistente.
Planifica backups y prueba restauraciones en cualquier papel. Las réplicas ayudan a disponibilidad, pero no sustituyen copias de seguridad. Define pérdida y tiempo de recuperación aceptables en la configuración real.
Para pedidos mantendría registros transaccionales en una base que cumpla sus reglas y añadiría Elasticsearch si la búsqueda lo justifica. Para documentos independientes orientados a búsqueda, comprobaría si basta para almacenamiento, consistencia y recuperación.
Recuerda: elige por garantías necesarias y verifica fallos y recuperación. La velocidad de búsqueda es solo parte de la decisión.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar