Em março de 2023, a equipe de engenharia da Amazon Prime Video publicou um post técnico que causou bastante repercussão na comunidade de cloud: eles haviam redesenhado um de seus serviços internos, saindo de uma arquitetura distribuída baseada em serverless para uma aplicação monolítica rodando em containers — e reduziram o custo operacional em 90%. O caso ficou conhecido de forma simplificada como "Prime Video abandona microsserviços", mas essa leitura esconde um detalhe importante: o problema não estava no conceito de microsserviços em si, e sim em como serverless (Step Functions e Lambda) havia sido usado para orquestrar um fluxo de altíssima frequência de eventos. Vale entender o caso com mais profundidade, porque as lições dele valem para qualquer arquiteto de cloud que precisa decidir entre desacoplar componentes ou simplificar a orquestração. O serviço em questão: monitoramento de qualidade de áudio/vídeo O time responsável era o de Video Quality Analysis (VQA), que mantém uma ferramenta capaz de detectar problemas de qualidade em streams de vídeo em tempo real — coisas como corrupção de blocos de imagem, congelamento de vídeo e dessincronização entre áudio e vídeo. Essa ferramenta já existia, mas não havia sido projetada para operar na escala de milhares de streams simultâneos, que é o volume real de tráfego da Prime Video. A arquitetura original A primeira versão do serviço foi construída como um sistema distribuído usando componentes serverless, o que fazia todo sentido do ponto de vista de velocidade de entrega. Em linhas gerais, o desenho contava com: Media Converter: um componente responsável por quebrar os streams de áudio/vídeo em frames de imagem e buffers de áudio decodificados. Defect Detectors: microsserviços que analisavam esses frames e buffers usando algoritmos de machine learning para identificar defeitos, executados via AWS Lambda. Orquestração via AWS Step Functions: controlando as transições de estado entre as etapas do pipeline de análise. Amazon S3: usado como armazenamento intermediário, guardando os frames de imagem entre uma etapa e outra do pipeline. Amazon SNS: usado para notificar os resultados da análise. Esse desenho tinha uma vantagem clara: escalabilidade horizontal teórica, já que cada componente poderia escalar de forma independente, e uma implementação rápida, aproveitando serviços gerenciados da AWS. Onde a conta não fechou O problema apareceu quando o serviço começou a operar em escala real. Dois gargalos concentraram praticamente todo o impacto negativo: 1. Step Functions como orquestrador de alta frequência. O fluxo realizava múltiplas transições de estado a cada segundo de stream analisado. Como o Step Functions cobra por transição de estado, e como existem limites de conta para volume de transições, o serviço atingiu limites de escala em torno de apenas 5% da carga esperada — bem abaixo do necessário para operar com todos os streams da plataforma. 2. Custo de chamadas de camada 1 ao S3. Passar frames de vídeo entre componentes usando S3 como intermediário gerava um volume enorme de chamadas de escrita e leitura (chamadas "tier-1", que são as mais caras no modelo de precificação do S3), o que tornava o custo de operação proibitivo em escala. Em resumo: o desenho não estava "errado" em teoria, mas o padrão de uso — altíssima frequência de eventos pequenos, orquestrados por um serviço que cobra por evento, trocando dados por um armazenamento intermediário que cobra por chamada — é exatamente o cenário em que orquestração serverless tende a sair cara. A nova arquitetura A solução da equipe foi consolidar as etapas do pipeline (conversão de mídia e detecção de defeitos) em um único processo, eliminando a orquestração via Step Functions e a troca de dados via S3. Os frames passaram a ser transferidos em memória, dentro do mesmo processo, e não mais por chamadas de rede a um serviço de armazenamento. Essa aplicação consolidada passou a rodar sobre EC2 e ECS, com uma camada leve de orquestração para distribuir as requisições dos clientes entre instâncias. Para lidar com o problema de escala vertical de um único processo, a equipe replicou o serviço em múltiplas tarefas ECS, cada uma com um subconjunto de detectores — ou seja, ainda existe distribuição de carga, só que em um nível de granularidade bem mais grosso do que antes. O resultado A mudança de arquitetura reduziu o custo operacional do serviço em 90% e resolveu o gargalo de escala, permitindo cobrir a totalidade dos streams monitorados. A lógica de negócio (os algoritmos de detecção de defeitos) permaneceu praticamente a mesma — o que mudou foi a camada de orquestração e transporte de dados entre etapas. Uma ressalva importante: monólito ou só "menos serverless"? O post original gerou um debate acalorado na comunidade técnica, incluindo críticas de arquitetos conhecidos do setor. O ponto central da discussão é que, tecnicamente, o novo desenho não é um monólito no sentido tradicional do termo: a Prime Video como um todo continua operando como um conjunto de serviços independentes (cobrança, catálogo, streaming, etc.), e mesmo o novo serviço de VQA ainda é replicado em múltiplas instâncias ECS. O que de fato mudou foi a granularidade da orquestração: em vez de fragmentar cada etapa do processamento em funções Lambda separadas e coordená-las por um serviço de estado que cobra por transição, a equipe passou a executar todas as etapas de um mesmo stream dentro de um único processo. É mais preciso descrever isso como uma migração de serverless orientado a eventos para compute tradicional em containers, do que como "microsserviços versus monólito" — ainda que essa segunda formulação tenha sido a usada no post original e seja a que pegou popularmente. Lições para quem projeta arquiteturas em cloud Alguns pontos ficam claros ao analisar o caso: O modelo de cobrança do serviço gerenciado importa tanto quanto sua elasticidade. Step Functions e Lambda são excelentes para orquestrar fluxos de baixa a média frequência ou eventos assíncronos, mas cobrar por transição de estado ou por invocação se torna um problema quando a frequência de eventos é da ordem de múltiplas vezes por segundo, por stream, multiplicado por milhares de streams simultâneos. Armazenamento intermediário tem custo de chamada, não só de armazenamento. Usar S3 como "fila" ou buffer entre etapas de um pipeline parece simples, mas o custo por operação pode superar rapidamente o custo do armazenamento em si, especialmente em payloads pequenos e frequentes. Desacoplamento tem um custo de rede e serialização que nem sempre se paga. Quando as etapas de um pipeline sempre são executadas juntas, para o mesmo item de trabalho, colocá-las no mesmo processo elimina overhead de rede sem necessariamente sacrificar a capacidade de escalar — desde que a unidade de escala (nesse caso, a instância ECS) seja bem dimensionada. A escolha de arquitetura depende do padrão de acesso, não de uma regra geral. O próprio caso não é uma prova de que "monólitos são melhores que microsserviços" — é uma prova de que a granularidade da orquestração precisa ser compatível com a frequência e o volume dos eventos que ela processa. Conclusão O caso da Prime Video se tornou um símbolo do debate entre microsserviços e monólitos, mas seu valor real está em outro lugar: ele mostra como escolhas de orquestração e transporte de dados, tomadas cedo no design de um sistema, podem determinar se uma arquitetura escala de forma sustentável ou colide com limites de conta e custos inesperados assim que sai do piloto para a produção em escala real. Antes de escolher entre serverless, containers ou uma combinação dos dois, vale simular o padrão real de tráfego esperado e o modelo de cobrança de cada serviço envolvido — não só a elegância teórica do desenho distribuído. Fontes Prime Video Tech Blog — Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% InfoQ — Prime Video Switched from Serverless to EC2 and ECS to Save Costs The New Stack — Amazon Prime Video's Microservices Move Doesn't Lead to a Monolith after All