Respuesta.

La minimización de la conexión (loose coupling) entre microservicios es uno de los principales principios de la arquitectura moderna. Esto se logra a través de la interacción asíncrona (a través de colas de mensajes o un bus de eventos), evitando llamadas HTTP síncronas directas sin necesidad y definiendo contratos API claros.

Una forma popular es utilizar brokers de mensajes (RabbitMQ, Kafka, NATS), donde los microservicios publican eventos sobre su estado, y los suscriptores reaccionan a ellos.

Ejemplo de publicación y procesamiento de eventos en Kafka con Node.js:

// producer.js
const { Kafka } = require('kafkajs')
const kafka = new Kafka({ clientId: 'order-service', brokers: ['kafka01:9092'] })
const producer = kafka.producer()
await producer.connect()
await producer.send({ topic: 'orders', messages: [ { value: JSON.stringify({orderId: 123}) } ] })
await producer.disconnect()

// consumer.js
const consumer = kafka.consumer({ groupId: 'payment-group' })
await consumer.connect()
await consumer.subscribe({ topic: 'orders', fromBeginning: true })
await consumer.run({ eachMessage: async ({ topic, partition, message }) => {
  const order = JSON.parse(message.value.toString())
  // procesamiento del pedido
}})

Características clave:

• Los microservicios se comunican a través de un API formalizado o un intermediario (cola, bus)
• Cada servicio tiene su propia base de datos (Database per Service) para evitar bloqueos y competencia
• Es posible conectar nuevos servicios sobre la marcha sin modificar los existentes

Preguntas capciosas.

Pregunta: ¿Se puede utilizar una base de datos compartida para varios microservicios si se trata de un gran proyecto?

No, esto viola el principio de independencia, conduce a un tight coupling, empeora la escalabilidad y el mantenimiento. Se deben usar bases de datos o esquemas separados.

Pregunta: ¿Es aceptable la interacción HTTP síncrona entre los servicios como una práctica al escalar el sistema?

Las solicitudes HTTP síncronas se escalan mal y pueden convertirse en un bottleneck. Se recomienda aplicar mecanismos asíncronos y solo en caso de absoluta necesidad recurrir a llamadas síncronas.

Pregunta: ¿Se puede escalar un microservicio solo aumentando el número de sus instancias sin cambiar la arquitectura del sistema?

No, aumentar simplemente el número de instancias no resuelve los problemas de conexión o de cuellos de botella en la arquitectura. Se requiere un análisis de los cuellos de botella, la implementación de colas, el almacenamiento en caché y la división de responsabilidades entre los servicios.