Teve uma situa\u00e7\u00e3o que, olhando hoje, explica melhor do que qualquer teoria por que sistemas n\u00e3o quebram do jeito que a gente imagina.<\/p>\n\n\n\n
O sistema estava rodando bem. C\u00f3digo revisado, testes passando, deploy tranquilo. Nada fora do padr\u00e3o. At\u00e9 que come\u00e7aram a aparecer alguns casos estranhos: pedidos marcados como pagos, mas que nunca tinham sido faturados. N\u00e3o era um volume absurdo, mas era o suficiente pra gerar desconforto. E o pior, acontecia de forma intermitente, sem um padr\u00e3o claro.<\/p>\n\n\n\n
A primeira rea\u00e7\u00e3o foi a mais \u00f3bvia: tem um bug a\u00ed<\/strong>.<\/p>\n\n\n\n Algu\u00e9m deve ter deixado passar alguma condi\u00e7\u00e3o, algum fluxo n\u00e3o tratado, alguma valida\u00e7\u00e3o mal posicionada. Come\u00e7amos a olhar o c\u00f3digo com esse vi\u00e9s. Revisamos o fluxo de pagamento, depois o de faturamento, depois as integra\u00e7\u00f5es. Tudo parecia correto. Isoladamente, cada parte fazia exatamente o que deveria fazer.<\/p>\n\n\n\n E \u00e9 a\u00ed que come\u00e7a a parte que muda o jogo.<\/p>\n\n\n\n O problema n\u00e3o estava em nenhuma dessas pe\u00e7as individualmente. Ele s\u00f3 aparecia quando tudo acontecia junto. Um usu\u00e1rio finalizava o pagamento ao mesmo tempo em que uma integra\u00e7\u00e3o externa confirmava o status com um pequeno delay. Em paralelo, um worker processava uma fila que tamb\u00e9m reagia a esse evento. Em alguns cen\u00e1rios, a ordem dessas coisas mudava alguns milissegundos. E isso j\u00e1 era suficiente.<\/p>\n\n\n\n Nada estava errado<\/strong> no c\u00f3digo.<\/p>\n\n\n\n Mas o estado final dos dados ficava inconsistente<\/strong>.<\/p>\n\n\n\n Esse tipo de problema \u00e9 trai\u00e7oeiro porque quebra o modelo mental mais comum sobre erro em software. A gente aprende a procurar bugs como se fossem falhas localizadas, quase sempre ligadas a uma linha espec\u00edfica de c\u00f3digo. S\u00f3 que, na pr\u00e1tica, sistemas reais falham muito mais por causa da intera\u00e7\u00e3o entre partes corretas do que por causa de uma parte isoladamente errada.<\/p>\n\n\n\n Quando voc\u00ea tem m\u00faltiplos processos acontecendo ao mesmo tempo, usu\u00e1rios interagindo, filas sendo processadas, integra\u00e7\u00f5es externas respondendo fora de ordem, retries acontecendo automaticamente, o sistema deixa de ser previs\u00edvel de forma linear. Ele passa a depender da combina\u00e7\u00e3o desses eventos. E nem sempre essa combina\u00e7\u00e3o foi pensada quando o c\u00f3digo foi escrito.<\/p>\n\n\n\n \u00c9 assim que surgem estados que ningu\u00e9m antecipou. Um pedido pago que n\u00e3o dispara faturamento. Um registro criado sem sua depend\u00eancia. Um processo executado duas vezes porque recebeu o mesmo evento em momentos diferentes. E o mais perigoso, tudo isso acontecendo sem nenhum erro expl\u00edcito sendo lan\u00e7ado.<\/p>\n\n\n\n Com o tempo, voc\u00ea percebe que o trabalho muda de natureza. J\u00e1 n\u00e3o \u00e9 mais s\u00f3 sobre escrever c\u00f3digo que funciona em condi\u00e7\u00f5es ideais. \u00c9 sobre garantir que, mesmo sob concorr\u00eancia, lat\u00eancia, retries e eventos fora de ordem, o sistema continue consistente.<\/p>\n\n\n\n E \u00e9 por isso que conceitos que antes pareciam exagero come\u00e7am a fazer sentido de forma muito pr\u00e1tica. Transa\u00e7\u00f5es<\/strong> deixam de ser detalhe e viram prote\u00e7\u00e3o real de consist\u00eancia. Idempot\u00eancia<\/strong> vira defesa contra duplicidade. Controle de concorr\u00eancia<\/strong> evita disputa silenciosa de dados. Eventos<\/strong> precisam ser bem definidos. Reprocessamento<\/strong> precisa ser seguro.<\/p>\n\n\n\n N\u00e3o \u00e9 paranoia de engenheiro.<\/p>\n\n\n\n \u00c9 adapta\u00e7\u00e3o \u00e0 realidade.<\/p>\n\n\n\n Porque, em algum momento, todo sistema que cresce deixa de ser apenas um conjunto de fun\u00e7\u00f5es bem escritas e passa a ser um organismo cheio de estados poss\u00edveis, reagindo a est\u00edmulos que nem sempre chegam na ordem esperada.<\/p>\n\n\n\n E quando voc\u00ea entende isso, voc\u00ea para de ca\u00e7ar bug como se fosse o \u00fanico problema.<\/p>\n\n\n\n E come\u00e7a a projetar comportamento<\/strong>.<\/p>\n\n\n\n \u00c9 a\u00ed que a engenharia muda de n\u00edvel.<\/p>\n\n\n\n E, sendo bem direto, \u00e9 a\u00ed que o jogo come\u00e7a a ficar s\u00e9rio.<\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" O problema n\u00e3o \u00e9 o bug. \u00c9 o estado do sistema. Japa Tela Preta #4 Teve uma situa\u00e7\u00e3o que, olhando hoje, explica melhor do que qualquer teoria por que sistemas n\u00e3o quebram do jeito que a gente imagina. O sistema estava rodando bem. C\u00f3digo revisado, testes passando, deploy tranquilo. Nada fora do padr\u00e3o. At\u00e9 que […]<\/p>\n","protected":false},"author":8,"featured_media":3872,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35,34],"tags":[39,41,42,36,40,37,38,43],"class_list":["post-3857","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-japa-tela-preta","category-tecnologia","tag-arquiteturadesoftware","tag-desenvolvimentodesoftware","tag-engenhariadesoftware","tag-japatelapreta","tag-programacao","tag-softwareengineering","tag-systemdesign","tag-techlead"],"acf":[],"yoast_head":"\n