¿Cómo evitas que un cambio en el backend rompa a los clientes que consumen tu API?

Haz que el contrato sea comprobable por máquina. Mantén un esquema, un documento OpenAPI o definiciones protobuf, generado desde el código o validado contra él, y ejecuta en CI una comprobación de compatibilidad que falle ante un cambio incompatible como un campo eliminado o un tipo más estricto. Añade pruebas de contrato dirigidas por el consumidor para los clientes internos, y versiona los eventos igual que versionas los endpoints.

El contrato tiene que ser un archivo que CI pueda comparar, porque si no la compatibilidad depende de quien revise la pull request. Así que el documento OpenAPI vive en el repositorio y se genera desde los manejadores, lo que evita que se convierta en ficción, y hay un job que lo compara con la versión de la rama principal y falla ante cualquier cosa incompatible: un campo eliminado, un parámetro nuevo obligatorio, un tipo más estrecho. Añadir siempre está permitido. Para los consumidores internos me gustan los contratos dirigidos por el consumidor, donde cada cliente publica el subconjunto del que depende de verdad y mi build verifica que sigo cumpliéndolos todos, así me entero al construir y no por su guardia. Los eventos reciben el mismo trato mediante un registro de esquemas con un modo de compatibilidad configurado, ya que un payload de evento roto es peor que un endpoint roto porque los consumidores fallan de forma asíncrona. Y antes de cambiar nada reviso las métricas de peticiones por cliente, porque el contrato me dice qué es posible y las métricas me dicen quién lo notaría de verdad.