Como você impede que uma mudança de backend quebre os clientes que consomem sua API?

Torne o contrato verificável por máquina. Mantenha um schema, um documento OpenAPI ou definições protobuf, gerados a partir do código ou validados contra ele, e rode uma checagem de compatibilidade no CI que falhe em qualquer mudança que quebre, como um campo removido ou um tipo restringido. Adicione testes de contrato guiados pelo consumidor para clientes internos, e versione eventos do mesmo jeito que você versiona endpoints.

O contrato precisa ser um arquivo que o CI consiga comparar, senão a compatibilidade depende de quem revisa o pull request. Então o documento OpenAPI mora no repositório e é gerado a partir dos handlers, o que impede que ele vire ficção, e existe um job que faz o diff contra a versão da branch principal e falha em qualquer coisa que quebre: um campo removido, um novo parâmetro obrigatório, um tipo estreitado. Adicionar coisas é sempre permitido. Para consumidores internos eu gosto de contratos guiados pelo consumidor, em que cada cliente publica o subconjunto do qual realmente depende e meu build verifica que continuo satisfazendo todos, então eu descubro no build e não pelo plantão deles. Eventos recebem o mesmo tratamento por um registro de schemas com um modo de compatibilidade definido, já que um payload de evento quebrado é pior que um endpoint quebrado, porque os consumidores falham de forma assíncrona. E antes de mudar qualquer coisa eu olho as métricas de requisição por cliente, porque o contrato me diz o que é possível e as métricas me dizem quem realmente notaria.