Una arquitectura dirigida por eventos conecta componentes mediante hechos que ya han ocurrido
La arquitectura de eventos es un estilo de diseño de software en el que los componentes publican hechos relevantes y otros componentes reaccionan a ellos. «Pedido confirmado», «pago recibido» o «sensor superó el umbral» son eventos: describen algo ocurrido. El productor no necesita llamar directamente a cada sistema interesado. Publica el evento en un canal y consumidores independientes lo procesan para enviar un correo, actualizar inventario o generar una alerta sin bloquear necesariamente la operación original.
Ese desacoplamiento permite añadir consumidores sin modificar al productor y absorber ritmos diferentes. Una tienda puede confirmar una compra aunque el servicio de recomendaciones tarde unos segundos. Sin embargo, mover la comunicación a un intermediario no elimina dependencias: las desplaza a contratos de datos, expectativas temporales y reglas de entrega. Si cambia el significado de «pedido confirmado», todos los consumidores afectados deben comprender la nueva versión.
Un evento cuenta un hecho; un comando solicita una acción; una consulta pide información
«Cobra este pedido» es un comando dirigido a quien puede ejecutarlo y puede ser rechazado. «Pedido cobrado» es un evento en pasado y no ordena una respuesta concreta. «¿Cuál es el estado del pago?» es una consulta que espera datos. Mezclar estas formas vuelve ambiguo el sistema: un mensaje llamado evento que en realidad manda actuar conserva un acoplamiento oculto entre emisor y receptor.
Los eventos suelen ser notificaciones compactas o mensajes con datos suficientes para procesar. Incluir muy poco obliga a consultar al productor y reduce autonomía; incluir copias completas aumenta tamaño y riesgo de datos obsoletos o sensibles. El contrato debe expresar identificador, tipo, momento, versión y contexto necesario. La elección depende de consistencia, privacidad y coste, no de una regla universal de «más datos es mejor».
Dos canales parecidos reparten los mensajes de manera diferente
En una cola de trabajo, varios consumidores compiten y normalmente solo uno procesa cada mensaje. Sirve para repartir tareas. En publicación-suscripción, cada suscriptor recibe su propia copia lógica del evento, de modo que facturación, analítica y notificaciones pueden reaccionar por separado. Algunos intermediarios combinan ambos modelos mediante temas, particiones y grupos de consumidores.
La arquitectura no exige una tecnología concreta. Puede usar un broker, un registro distribuido o mecanismos de nube. Los microservicios tampoco implican eventos: pueden comunicarse por HTTP de forma síncrona. Los eventos resultan útiles cuando varias reacciones pueden ocurrir después, hay picos de carga o interesa conservar un flujo reproducible. Una solicitud que necesita respuesta inmediata quizá sea más clara como llamada directa.
La red puede repetir o reordenar mensajes, así que el consumidor debe estar preparado
Prometer entrega exactamente una vez de extremo a extremo es difícil porque un proceso puede completar una operación y fallar antes de confirmar el mensaje. El intermediario lo enviará de nuevo. Por eso se diseñan consumidores idempotentes: procesar dos veces el mismo identificador produce el mismo estado que hacerlo una. Una tabla de mensajes procesados, claves únicas o actualizaciones condicionales evitan cobrar dos veces.
El orden global limita rendimiento y rara vez es necesario. A menudo basta preservar orden por pedido, cuenta o dispositivo mediante una clave de partición. Aun así, un evento tardío puede llegar después de otro más reciente. Marcas de versión y reglas de reconciliación ayudan. El tiempo del productor, el momento de recepción y el orden del broker son conceptos distintos; confiar solo en un reloj puede introducir errores sutiles.
Los componentes pueden ver estados diferentes durante un intervalo sin que el sistema esté roto
Tras confirmar un pedido, inventario puede actualizarse antes que analítica. Esa consistencia eventual es aceptable si el negocio conoce el retraso. No lo es cuando una decisión necesita una reserva inmediata. Las sagas coordinan transacciones distribuidas mediante pasos y compensaciones: si el envío no puede reservarse, se devuelve el pago. Una compensación no borra el pasado; ejecuta una nueva acción que contrarresta parte de sus efectos.
La observabilidad debe seguir una operación a través de mensajes. Identificadores de correlación, trazas, métricas de retraso y colas de mensajes fallidos permiten saber dónde se detuvo. Reintentar sin límites puede saturar un servicio; descartar silenciosamente pierde información. Un diseño profesional define tiempos, reintentos, vencimiento y respuesta ante datos que ningún consumidor puede procesar.
Comunicar eventos y guardar el estado como una secuencia de eventos son decisiones separadas
En event sourcing, el estado de una entidad se reconstruye a partir de una secuencia persistente de cambios. Una cuenta no guarda solo el saldo, sino depósitos y retiradas. Una arquitectura de eventos puede limitarse a publicar notificaciones mientras cada servicio mantiene tablas normales. También puede existir event sourcing dentro de un servicio sin divulgar todos sus eventos al resto del sistema.
El estilo aporta escalabilidad y extensibilidad, pero aumenta contratos, depuración y razonamiento temporal. No conviene adoptarlo solo porque parezca moderno. Antes hay que preguntar qué reacciones pueden ser asíncronas, qué orden importa, cuánto retraso se tolera y cómo se recuperará un fallo. Cuando esas respuestas están claras, los eventos convierten una cadena rígida de llamadas en una red adaptable; sin ellas, solo distribuyen la confusión.
También cambia la forma de probar el software. Una prueba debe verificar contratos, duplicados, mensajes tardíos y recuperación, no solo una respuesta inmediata. Reproducir un flujo registrado ayuda a diagnosticar, siempre que sus datos puedan usarse con seguridad. Diseñar estos escenarios desde el inicio evita que la primera caída real sea el único ensayo del sistema distribuido.
