Executando verificação de segurança...
4

COMO ESCALAMOS UM SISTEMA C# QUE LEVAVA 1H PARA PROCESSAR 1.000 OPERAÇÕES E REDUZIMOS PARA 10 MINUTOS

Recentemente eu e minha equipe entregamos um projeto desafiador em que revisitamos um sistema legado escrito em C#. Na versão antiga, todo o backend estava encapsulado num monólito .NET Framework, com algumas rotas expostas via WCF e hospedado atrás de um load balancer que distribuía tráfego para um grupo fixo de três instâncias EC2, sem qualquer mecanismo de auto scaling. Para completar, toda a leitura e escrita ocorriam no mesmo processo e os dados eram persistidos num SQL Server compartilhado — um cenário perfeito para bloqueios de banco de dados e filas de espera intermináveis sempre que múltiplas operações acessavam as mesmas tabelas.

Decidimos redesenhar completamente esse fluxo crítico. Em vez de processar tudo de uma vez, extraímos a etapa de ingestão para containers Docker, que rodam em clusters independentes e escalam horizontalmente com facilidade. Cada container agora envia lotes de registros diretamente para uma fila SQS, garantindo buffer, retries automáticos e desacoplamento total entre quem produz os dados e quem os consome.

No lado de consumo, migramos o processamento pesado para funções AWS Lambda acionadas pela própria fila SQS. Essas lambdas cuidam de todas as regras de negócio, transformações e enriquecimento de dados, aproveitando a elasticidade serverless para disparar dezenas ou centenas de instâncias em paralelo, conforme a demanda. O modelo “pague pelo que usar” também trouxe uma redução significativa de custos operacionais.

Após o processamento, os resultados são persistidos em um banco relacional no Amazon RDS. Aqui, aproveitamos transações ACID para manter a integridade e eliminamos a antiga disputa por locks, já que cada execução Lambda escreve em instâncias otimizadas para carga alta, sem interferir umas nas outras. Essa separação clara entre leitura, processamento e armazenamento foi fundamental para quebrar os gargalos históricos.

Conclusão? O impacto foi impressionante: o tempo total para processar 1.000 operações caiu de aproximadamente uma hora para apenas dez minutos. Além do ganho de performance, conquistamos maior resiliência — se um worker falha, a mensagem permanece na fila até ser reprocessada — e flexibilidade para evoluir cada componente sem afetar o restante da aplicação.

Essa migração reforçou uma lição que talvez seja a mais importante: arquitetura bem pensada faz tanta diferença quanto a tecnologia em si. Independente de escolher C#, Java, Go ou Node.js, é o desenho desacoplado — filas, containers, serverless e bancos dedicados — que garante throughput alto, latência previsível e manutenção simplificada.

Carregando publicação patrocinada...
0
0
1

Era uma aplicação interna que registrava todas as operações que a área de negócio fechava com o cliente. A grosso modo sempre que cliente finalizava um contrato (ex: uma compra de ação) o sistema entrava em ação para executar várias validações pesadas de posição, saldo, regras de compliance, documentação, etc.
Na arquitetura antiga, tudo era feito de forma síncrona, cada contrato rodava uma validação de cada vez — validação de posição, depois validação de saldo, depois compliance, e assim por diante. No design novo a gente paralelizou essas validações via lambda, que virou uma tarefa independente.

-1
-1

Acho engraçado, as pessoas tem medo de usar IA no dia a dia. "Ai é um texto gerado por IA", é melhor usar IA pra gerar um texto e compartilhar experiências com a comunidade do que ficar enchendo o saco de quem faz isso, mas obvio, falar mal é bem mais fácil.

Mas respondendo sua pergunta: Participei ativamente na criação das rotas usadas no docker bem como a integração com o SQS para processamento no lambda (os containers Docker mandavam diretamente no SQS via AWS SDK com as credenciais gerenciadas por IAM). A parte de apresentação com a área de negócio também foi feita por mim.