O printscreen que matou uma patrocínio
Dois telefones, um post, duas realidades diferentes. Sem crash, sem bug e sem solução que não começasse com o reconhecimento do verdadeiro problema.
O Halo é um aplicativo de compartilhamento de fotos com cerca de oito milhões de usuários ativos mensais e uma economia criadora acoplada ao lado. Na versão 5.4 do app, a equipe lançou algo pequeno e amado: uma 'badge trending' que aparece em um post quando ele se torna viral. A badge era calculada no dispositivo. Cada cliente observava o número de likes chegar durante toda a vida útil do post, estimava uma velocidade e, se essa cruzasse um limite, desenhava a pequena chama. Limpo, barato, sem novo backend. Foi demonstrado maravilhosamente bem e lançado numa quinta-feira.
A escalada chegou onze dias depois, e não foi um crash. As sessões sem falhas mantiveram-se em 99,91% o tempo todo. Um criador teve um post cruzar a linha de corte no seu telefone, tirou um printscreen da chama, e enviou para um gerente de marca como prova de que o post estava trending, parte de uma proposta para uma campanha paga. O gerente de marca abriu Halo em seu próprio telefone, olhou para o mesmo post e não viu a badge. Seu dispositivo havia se juntado tarde demais, estimou uma velocidade menor com base em um período mais curto e nunca cruzou a linha de corte. Para ele, o criador tinha falsificado um printscreen. O negócio morreu. Ela postou sobre isso. Dentro de um dia, o suporte recebeu duzentos tickets todos dizendo alguma versão de 'a badge trending é uma mentira.'
O engenheiro que pegou a escalada passou um dia inteiro provando que o código estava funcionando exatamente como escrito. É o pior tipo de incidente, aquele sem bug para consertar. Dois dispositivos observando o mesmo post calcularam duas realidades diferentes, porque cada um rodava seu próprio estimador sobre sua própria fatia do tempo e nada no design dizia que a badge tinha que significar a mesma coisa para todos olhando para o post.
Aqui está a frase que quero que você mantenha: onde um valor é calculado é uma decisão arquitetônica. A equipe a fez por reflexo, para evitar montar um backend e o reflexo prometeu silenciosamente algo que o produto não poderia manter: que uma badge pública é um fato compartilhado.
Por que mobile torna isso mais nítido
Se isso fosse um sistema backend, a história seria curta. Redeploy o serviço, a versão antiga deixa de existir, desculpe-se e siga em frente. Mobile nega tudo isso.
Na noite que o negócio morreu, três versões do Halo estavam ao vivo: 5.4 com a badge on-device, 5.3 em cerca de 31% dos ativos sem badge alguma e 4.9 em aproximadamente 4%, mantidos em dispositivos mais antigos cujos donos tinham o auto-update desligado. Qualquer decisão sobre a badge tinha que se manter para todas as três populações ao mesmo tempo, e continuaria tendo que fazer isso por meses.
A população móvel não pode ser assumida como atualizada, reconectada ou mesmo iniciada durante o período de remediação. O código, os dados persistidos, os contratos do SDK, a configuração e os binários distribuídos pela loja evoluem em velocidades diferentes, e a mais lenta define seu raio real de mudança. É isso que torna o design de sistemas móveis uma disciplina própria, e é por isso que grande parte do conteúdo sobre design de sistemas, escrito por e para engenheiros backend, falha silenciosamente com os engenheiros mobile. Os diagramas transferem. A realidade operacional não.
A lacuna que isso expõe em bons engenheiros
Eu avaliei centenas de designs ao longo dos anos, em entrevistas e revisões reais, e a lacuna recorrente é surpreendentemente consistente. Um engenheiro sênior forte pode desenhar a arquitetura alvo. O que eles frequentemente não conseguem fazer é dizer qual evidência justifica isso sobre o alternativo, qual suposição é mais provável de estar errada, como os primeiros 10% são lançados enquanto as versões antigas permanecem ativas ou o que acontece quando a adoção estaciona.
A insígnia é um pequeno exemplo dessa grande prática. A arquitetura não é o diagrama. A arquitetura é uma sequência governada de decisões reversíveis e irreversíveis, e o que sobrevive ao contato com a produção não são as caixas, mas sim as regras ao seu redor: qual promessa cada caixa faz, quem possui essa promessa, como você saberia se ela falhou e quais evidências fariam você derrubá-la.
Dez perguntas para avaliar um design
Suficiente teoria. Aqui está a revisão de decisão que agora eu faço com cada design, em sua totalidade. Faça essas perguntas antes de se comprometer e escreva as respostas.
- Problema é declarado sem nomear o mecanismo preferido?
- Qual estado ou decisão é autoritário?
- O que acontece após interrupção, timeout, duplicação ou configuração obsoleta?
- Quais populações de clientes e dados existentes permanecem ativas?
- A exposição pode ser limitada e observada separadamente?
- O que significa parar e o que significa desfazer para os clientes já atualizados?
- Qual equipe pode agir durante um incidente?
- Qual trabalho de compatibilidade temporária é introduzido?
- Quando e por quem é removido?
- O que seria a evidência para reverter essa decisão?
Passe a insígnia por essas perguntas e o fracasso se torna visível antes de uma única linha de código existir. A pergunta 2 não tem resposta: nenhum componente era autoritário para “tendências”, então cada telefone era. A pergunta 4 nunca foi feita: os usuários da versão 5.3 e 4.9 veriam nada, tornando a insígnia inapropriável por design. A pergunta 10 também não foi feita, então não havia sinal que captaria o desacordo antes de um gerente de marca fazê-lo.
Nenhuma dessas perguntas requer genialidade. Elas exigem decidir com propósito em vez de por reflexo, e exigem tratar “onde isso é computado” com a mesma seriedade que “o que isso calcula”.
De onde isso vem
Esta história é o caso de abertura do primeiro capítulo do meu livro, Mobile System Design Blueprint, um laboratório em funcionamento para evoluir, migrar, lançar e operar sistemas iOS e Android. Vinte capítulos de decisão, cada um construído sobre um caso de falha trabalhado como este aqui. Doze cenários que evoluem ao longo de cinco estágios e quebram no meio. Cinquenta exercícios pontuados e uma base de código acompanhante testada em Swift e Kotlin.
A amostra gratuita é este caso completo, levado mais longe do que este artigo vai. Está disponível em https://salari.dev/books/mobile-system-design-blueprint, e o preço de lançamento, 20% off com o código LAUNCH20, vai até 31 de julho.