Ontem eu falei de Arquitetura Evolutiva, entao nada melhor que dar um exemplo de como isso ja ocorreu comigo na pratica. Ja que nos ultimos anos estive trabalhando no Qual Canal, vou usa-lo como exemplo, mas isso ja aconteceu comigo em diversos outros sitemas e servicos. Para quem nao conhece, o QC e uma ferramenta que fornece inteligencia em cima dos comentarios presentes nas redes socias sobre programas de televisao.Quando comecei no projeto ele ja possuia um codigo existente. Consistia em um prototipo feito pelo Farinha e Anderson para experimentar como tratar os dados do twitter. Este prototipo ja realizava a coleta de dados, inseria em uma base MySQL e gerava um ranking, usando Django. Para quem conhece um pouco de processamento de Big Data sabe que essa nao e uma arquitetura ideal esse tipo de servico. Talvez para alguem mais versado no meio, a primeira decisao seria de jogar esse prototipo fora e comecar algo mais robusto. Porem, esse prototipo atendia perfeitamente a nossa necessidade na epoca. Essa era de validar como agregacao em ranking influenciava o publico, entao eu decidi usar aquele codigo como base para continuar os trabalhos.Essa decisao permitiu que tivessemos um foco maior na formatacao dos dados e como o usuario interagia com ele. Essa era a decisao mais barata naquele momento, pois esse era nosso foco de aprendizado na epoca. Apesar disso, eu nao estava disposto a deixar o sistema com jeitao de prototipo. Minha experiencia mostra que esse tipo de divida cobra juros caros no futuro. Por isso, decidi tambem investir em dois ajustes que considerei cruciais. Primeiro, em separar o consumo [e agregacao] de dados sociais da interface web. Dessa forma permitindo que o back-end fosse independente de como nosso usuario fosse interagir com os dados. Segundo, criar um conjunto de testes para me proteger de mim mesmo de besteiras que eu pudesse fazer, e possibilitar nosso deploy continuo. Nesse ponto, comecei criando os casos para as funcionalidades mais importantes ja existente, enquanto garantisse que as novas fossem sempre cobertas.Esta estrutura permitiu que o aprendizado evoluisse de forma gradativa por diversos meses, com a inclusao de diversas funcionalidades. Ate que sofremos a primeira cobranca por nao seguir uma arquitetura de Big Data. Naquele momento, nos tinhamos passado de alguns milhares de registros por dia, para esporadicos milhares por minuto. O que fazia nossa estrutura "congelar" por diversas horas. Converter nossa arquitetura para se adequar parecia muito caro. Nossa decisao foi de quebrar o processo de tratamento em varias fases, alem de multiprocessa-lo (alem de alguns truques na base de dados). Com isso, conseguimos manter a mesma base de codigo e chegar no patamar que desejavamos. Alem disso, com uma estrutura multiprocessada podiamos distribuir - mesmo que rudimentarmente - em diversas maquinas, conforme a necessidade.Essa estrutura durou mais de um ano sem apresentar problemas. Tempo esse que permitiu que muito aprendizado ocorresse. Inclusive tendo uma nova troca no mercado atendido pela ferramenta, alem das formas agregacao, interface e fontes de dados coletados. Neste tempo, a maior parte do esforco foi gasto no front-end e no