Por que a Prime Video trocou microsserviços serverless por um monólito

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 Top comments (0)