Cenário: deploy sem downtime e com rollback rápido
Pergunta
Você precisa publicar uma versão nova de um serviço com tráfego alto, sem downtime e com reversão rápida se der problema. Que estratégias de deploy servem e como diferem?
Resposta esperada
Blue-green: duas frotas idênticas; a nova versão sobe na frota ociosa ('green'), é testada, e o roteador vira 100% do tráfego pra ela de uma vez — rollback é virar de volta pra 'blue'. Rápido, mas troca tudo de uma vez e exige o dobro de capacidade. Canary: a nova versão recebe uma fatia pequena do tráfego (1–5%), você observa métricas de erro/latência, e vai aumentando gradualmente; rollback é cortar a fatia. Detecta problema com blast radius menor, ao custo de rodar duas versões ao mesmo tempo (precisa compatibilidade de schema/contrato). Rolling update é o meio-termo do orquestrador: substitui instâncias aos poucos. A resposta boa escolhe canary pra tráfego alto justamente pelo blast radius, e menciona a exigência de compatibilidade entre versões.
Por que perguntam isso
Cenário sênior. O que separa: citar 'blast radius' e a necessidade de compatibilidade de contrato/schema quando duas versões coexistem.