Apresentação: Dos DVDs ao streaming global: como a arquitetura de comércio da Netflix evoluiu na prática

Transcrição

Kasia Trapszo: Deixem-me levar-vos de volta ao ano de 2016, há apenas 10 anos, quando Reed Hastings, que na altura era o CEO da Netflix, fez o discurso de abertura na CES, a Feira de Electrónica de Consumo. Foi um discurso bastante bom. Ele falou sobre a história da televisão, a história do streaming, a Netflix, claro, tudo isso. O verdadeiro objetivo da palestra não era falar sobre a história da televisão, mas sim anunciar que a Netflix passaria a estar disponível a nível global. Íamos lançar o serviço em mais 130 países, todos ao mesmo tempo. Foi um momento muito importante para nós e foi muito emocionante. Para nós, que trabalhávamos na plataforma de comércio, foi um pouco assustador. Isto porque não se tratava apenas do anúncio de que íamos lançar o serviço, mas sim do próprio lançamento. Como o Reed disse, a Netflix já está disponível. Um grupo de engenheiros estava sentado numa cafetaria no Edifício B, em Los Gatos, à espera do sinal para ativarmos os nossos botões de ativação de funcionalidades individuais e, assim, concretizar o lançamento.

Porque lançar a Netflix a nível global não era como premir um grande botão vermelho, mas sim uma série de botões, uma série de chaves de ativação de funcionalidades, da responsabilidade de várias equipas de engenharia diferentes. Todos nós precisávamos de premir tudo mais ou menos ao mesmo tempo para que isto fosse viável. Estávamos todos sentados ali, o Reed disse a frase, e todos se apressaram, e assim, num instante, as inscrições foram ativadas, o streaming ficou disponível e o processamento de pagamentos foi ativado. Depois, limitámo-nos a observar os painéis de controlo. De alguma forma, tudo isto funcionou. Começámos a ver inscrições de países que nunca tínhamos suportado antes. Estávamos a processar pagamentos e as pessoas estavam a ver a Netflix. Foi um momento muito fixe de se fazer parte. Também foi um pouco assustador, porque a plataforma de comércio que impulsionou esse lançamento não tinha sido construída para uma empresa global de streaming. Tinha sido concebida para um pequeno negócio de envio de DVDs pelo correio, sediado nos EUA. Esta palestra é a história de como esse sistema evoluiu. Foi através de uma série de compromissos muito reais e, por vezes, muito confusos, à medida que o negócio continuava a expandir-se.

Contexto

Chamo-me Kasia Trapszo. Sou engenheira principal na Netflix. Trabalho principalmente na plataforma de comércio. Entrei para a Netflix há cerca de 11 anos. Quando entrei, a empresa tinha menos de 2 000 colaboradores a nível global. Menos de metade desses eram engenheiros. Parece mesmo ridículo dizer isto hoje em dia, mas crescemos bastante. Entrei para a equipa de pagamentos. Quando entrei, a equipa estava a meio da migração dos nossos serviços de pagamento para a nossa infraestrutura na nuvem. Desde então, comecei a trabalhar de forma mais abrangente na plataforma de comércio, que inclui o nosso sistema de faturação, direitos de acesso e processamento de pagamentos. Tive uma visão em primeira mão de como esse sistema evoluiu à medida que a Netflix se tornou na plataforma de streaming que é hoje.

A evolução da arquitetura não é simples

Uma das coisas que se aprende rapidamente quando se trabalha em algo assim é que a evolução da arquitetura nunca é simples. Não se pode redesenhar o sistema de dois em dois anos. Ele evolui porque o negócio evolui. Surge novos mercados, novos métodos de pagamento, novos modelos de negócio. Com todas essas mudanças, surgem novos padrões de utilização. Na maioria das vezes, os engenheiros não podem simplesmente parar o sistema e redesenhá-lo do zero. É preciso fazê-lo evoluir enquanto está em funcionamento. Consegue imaginar sentar-se com a equipa de produto e dizer: «Vamos disponibilizar-vos essas funcionalidades, mas talvez tenhamos de suspender as subscrições durante as próximas duas semanas.» Não é uma conversa que alguém queira ter. O que quero partilhar hoje não é uma história sobre uma arquitetura perfeita. É uma história sobre como um sistema real evolui ao longo do tempo.

Como tudo começou

Antes de a Netflix começar a expandir-se globalmente, os pressupostos do sistema eram incrivelmente simples. Como disse anteriormente, começámos como um negócio de envio de DVDs por correio com sede nos EUA, o que significava que tínhamos um modelo de pagamentos incrivelmente simples. A maioria dos consumidores nos EUA paga com cartões de crédito e, pelo menos nos EUA, os cartões de crédito são incrivelmente fáceis de utilizar online. Se todos os seus consumidores pagam com cartões de crédito, a cobrança recorrente é incrivelmente simples. Se quiser ser um pouco mais ousado, como nós fomos, pode introduzir o PayPal. O PayPal faz um bom trabalho ao abstrair toda uma série de métodos de pagamento diferentes por trás de uma fachada simples em tempo real. Agora tínhamos os nossos cartões de crédito, tínhamos o PayPal, e ambos suportavam a autorização em tempo real. Ambos davam-nos feedback imediato sobre se os pagamentos eram válidos, o que significa que também dávamos confirmação imediata. Em termos de arquitetura, o sistema de comércio na altura era incrivelmente simples.

Pode pensar nele como quatro componentes principais. Tínhamos os pagamentos e a faturação e, depois, os nossos sistemas de adesão e de direitos de acesso. Esses sistemas estavam a cargo de apenas duas equipas de engenharia. Os pagamentos e a faturação constituíam, essencialmente, um sistema central que tratava de tudo, desde cobrar a um cliente até armazenar os métodos de pagamento. Também realizava as renovações mensais das subscrições com tentativas de repetição e, em seguida, gerava um sinal simples de sucesso ou falha que era enviado diretamente para o sistema de direitos de acesso. Se a cobrança fosse bem-sucedida, os clientes obtinham acesso. Se falhasse e as tentativas de repetição se esgotassem, o acesso seria interrompido. Havia uma ligação muito clara entre o estado do pagamento e o estado dos direitos de acesso. O próprio modelo de novas tentativas também estava altamente otimizado para subscrições recorrentes. Recebíamos os nossos códigos de retorno do processador, como é habitual, classificávamos-os e, em seguida, utilizávamos esses códigos para decidir como e quando tentar novamente um pagamento falhado. Tudo estava bastante bem ajustado para este modelo de faturação mensal previsível.

Como mencionei, como todos utilizamos cartões de crédito e PayPal, tudo era autorizado em tempo real. Como dispúnhamos de feedback em tempo real, as tentativas de fraude podiam, na sua maioria, ser filtradas na fase de autorização, pelo que as decisões relativas ao direito de acesso podiam ser tomadas instantaneamente. Do ponto de vista arquitetónico, este sistema estava extremamente otimizado para subscrições recorrentes previsíveis com validação de pagamentos em tempo real. O cliente paga, o cliente obtém acesso. O pagamento falha, o acesso é interrompido. A nova tentativa é bem-sucedida, o acesso é retomado. Simples, fácil de compreender e bastante fácil de operar. Claro que, desde que o mundo inteiro se comportasse como o sistema de pagamentos dos EUA, funcionava muito bem.

Pressuposto: a arquitetura reflete a realidade

Antes de começarmos verdadeiramente a expandir-nos internacionalmente, aconteceu outra coisa de que tenho quase a certeza de que a maioria das pessoas não se lembra. Em 2011, anunciámos que a Netflix se dividiria em dois negócios distintos. O envio de DVDs por correio passaria a ser uma empresa com um nome fantástico chamada Qwikster. O streaming continuaria a ser a Netflix. Será que algum de vocês se lembra mesmo disto? Alguém se lembra disto? Também se lembram do impacto que isto teve. A reação negativa dos consumidores foi significativa. As pessoas não ficaram nada satisfeitas com a ideia de ter de gerir duas contas separadas, duas faturas separadas, dois sites separados e pagar mais do que antes. Cerca de três semanas depois, revimos a decisão. Acabou-se a Qwikster. Tudo permanece sob uma única marca Netflix. Podem perguntar-se: o que é que isto tem a ver com a plataforma de comércio? Eis o que a maioria das pessoas desconhece. Revertemos a marca. Não revertemos as alterações ao sistema. Em termos de arquitetura, o aluguer de DVDs e o streaming já tinham começado a separar-se. Estavam a tornar-se dois negócios de subscrição distintos, com direitos diferentes, processos de entrega diferentes e modelos económicos diferentes.

Embora o consumidor visse uma única fatura da Netflix, por baixo disso, estávamos, na verdade, a operar duas subscrições que eram combinadas na camada de faturação. A experiência do consumidor era de uma única empresa, mas a arquitetura indicava que eram dois negócios a serem conciliados. Essa camada de conciliação — a união de duas subscrições numa única fatura — acrescentou uma complexidade que carregámos durante anos. Encerrámos o serviço de DVD em setembro de 2023. Esse padrão, em que o negócio toma uma decisão e o sistema a implementa. A decisão é revertida, mas o sistema não. Ver-se-á isto frequentemente em arquiteturas de longa duração, incluindo esta.

Pressuposto: o mundo funciona como os EUA

Nesta altura, mal tínhamos começado a expandir-nos internacionalmente. O primeiro país para onde nos expandimos foi o nosso vizinho do norte, o Canadá. Uma economia muito semelhante à dos EUA. Continua a ser incrivelmente centrada nos cartões de crédito. Não aprendemos realmente muito com esse lançamento, exceto o estereótipo de que os canadenses são pessoas simpáticas. É verdade, e é merecido. Depois, expandimo-nos para sul, para a América Latina: Brasil, Argentina, México, e logo no primeiro dia tivemos um grande número de inscrições. Na altura, oferecíamos um período de teste gratuito, por isso ainda não estávamos a cobrar dinheiro às pessoas, mas estávamos a autorizar os métodos de pagamento para os armazenar para uso futuro. Tudo parecia correr muito bem, até ao segundo dia. Foi então que as coisas começaram a parecer muito menos promissoras. Começámos a ver um grande número desses pagamentos que tínhamos autorizado a serem rejeitados. Foi aí que aprendemos algo bastante importante. Afinal, no Brasil, na altura — estamos em 2011 —, os clientes não estavam a usar cartões de crédito.

Usavam, na sua maioria, cartões de débito. Naquela altura, a maioria dos cartões de débito no Brasil não estava, na verdade, habilitada para transações online. Enquanto o nosso sistema pensava que estávamos a receber todas estas excelentes inscrições, o que estávamos realmente a receber era a confirmação de que, sim, o cartão parecia válido, mas não podíamos, de facto, cobrar aos clientes. Do ponto de vista arquitetónico, isto quebrou um pressuposto fundamental do nosso sistema: que a validação do pagamento ocorre no momento do registo. O nosso sistema tinha sido concebido para que, assim que um método de pagamento fosse autorizado, pudéssemos considerá-lo válido com segurança e, em seguida, conceder o acesso ao serviço (o streaming), mas esse pressuposto deixou de se verificar. O verdadeiro método de pagamento online no Brasil naquela altura, mais uma vez, em 2011, era essencialmente o débito direto e as transferências bancárias. Trata-se de um processo em que o consumidor transfere dinheiro da sua conta bancária diretamente para o comerciante. Isto introduziu algo que nunca tínhamos realmente tido de fazer antes: as confirmações de pagamento atrasadas. Com os cartões de crédito, como todos sabem, a autorização é feita em tempo real e sabe-se imediatamente se o método de pagamento é válido.

Com o débito direto, as transações são enviadas ao banco num ficheiro, como um ficheiro em lote, e depois é preciso esperar. Às vezes, demora um dia. Em alguns bancos, dois ou três dias. Na época do Carnaval no Brasil, o país inteiro fica paralisado durante uma semana. Agora tínhamos clientes a registarem-se com contas bancárias e, durante dias, nem sequer sabíamos se essas contas eram realmente válidas. Isto obrigou à implementação da primeira arquitetura significativa no sistema de comércio. Até aquele momento, a faturação e os pagamentos funcionavam quase inteiramente em tempo real. A autorização ocorria imediatamente. As decisões aprovadas também podiam ser tomadas imediatamente. Fluxo de pagamentos. O débito direto alterou isso.

Agora precisávamos de uma forma de enviar transações aos bancos, aguardar uma resposta e, em seguida, reconciliar essas respostas no sistema. Introduzimos o nosso primeiro processamento em lote, e o sistema tratava da geração dos ficheiros bancários, do seu envio, da receção das respostas assíncronas e da integração desses dados no faturamento e nos direitos de acesso. Em termos de arquitetura, passámos de uma plataforma puramente em tempo real para um modelo híbrido, onde tivemos de suportar tanto o tempo real como estes sinais de pagamento atrasados. É claro que, assim que se introduz um sinal de pagamento atrasado num sistema que foi construído para funcionar em tempo real, começam a falhar muitas das premissas. Anteriormente, o modelo de direitos era muito simples. Se o pagamento fosse bem-sucedido, concedia-se o acesso; se falhasse, o acesso era suspenso. Agora, tínhamos de tomar decisões relativas aos direitos antes mesmo de sabermos se o pagamento seria efetivamente bem-sucedido. Se concedêssemos o streaming imediatamente, correríamos o risco de dar acesso gratuito a contas que talvez nunca nos pagassem.

Se adiássemos o acesso até recebermos a confirmação da validação, estaríamos a proporcionar uma experiência de cliente bastante negativa. Tivemos de introduzir alguns conceitos novos: janelas de validação, retenções temporárias, direitos condicionais. São todas coisas de que nunca tivemos realmente necessidade antes. É claro que isto também alterou profundamente a forma como encarávamos a fraude. Com cartões de crédito, é possível filtrar provavelmente 90% da fraude já na fase de autorização. Com o débito direto, sem essa rejeição em tempo real, os infratores podiam criar várias contas com dados bancários inválidos, e demoraríamos dias a detetar isso. A deteção de fraudes passou da autenticação em tempo real para a deteção comportamental ao longo do tempo, o que exigiu não só novos sinais e novas respostas operacionais, mas também novas integrações com fornecedores. A América Latina tornou-se a nossa primeira lição concreta de que o mundo não se vai comportar como os EUA. O Brasil desmentiu todas as nossas suposições. Quando se vê isso a acontecer num mercado, começa-se a perceber que isto vai continuar a acontecer. Porque, se cada mercado se comporta de forma diferente, então o nosso lançamento global não é apenas uma implementação. Torna-se um problema de arquitetura.

O Lançamento Global

Passando agora para 2015, decidimos expandir-nos um pouco mais lentamente e lançar o serviço em vários países. A América Latina já estava em pleno funcionamento e a dar-se bem. Lançámos o serviço em várias partes da Europa e estamos a aprender como as pessoas gostam de pagar em diferentes países. Algumas das coisas que aprendemos: na Itália, por exemplo, as pessoas gostam de pagar com cartões pré-pagos. Na Alemanha, por débito direto. Felizmente, nessa altura, já tínhamos passado pela experiência no Brasil. Tínhamos aprendido. Tínhamos aprendido a suportar métodos de pagamento que não funcionavam como cartões de crédito. Também lançámos o serviço em partes da Ásia. Lançámos no Japão. Foi uma excelente experiência em termos de como construir interfaces de utilizador, mas não tanto no que diz respeito aos pagamentos. No final de 2015, o nosso portfólio de métodos de pagamento incluía carteiras digitais e integrações de faturação com parceiros, como a Vodafone, a Comcast e a Orange. Neste caso, é o parceiro que trata da faturação propriamente dita e apenas nos envia uma notificação quando o cliente tiver efetuado o pagamento.

Aprendemos isto ao expandir-nos mercado a mercado. Depois veio o grande passo: o lançamento global. Foram cerca de 130 países, todos ao mesmo tempo. Nessa altura, já sabíamos uma coisa com toda a clareza: cada mercado comporta-se de forma diferente. Não há forma realista de localizar na perfeição 130 países em simultâneo, a menos que se esteja disposto a dedicar anos a isso. Nós não estávamos dispostos a fazê-lo. Tomámos algumas decisões muito deliberadas para encontrar atalhos a nível de arquitetura e de produto. Em vez de localizar totalmente as moedas, os métodos de pagamento e os preços em cada mercado, simplificámos. Dividimos o mundo num pequeno número de zonas de faturação. Se estiveres em partes da Europa, digamos, na Polónia, a faturação é feita em euros, e não em złoty. Se estiveres em partes da Ásia, como a Tailândia, faturamos-te em dólares americanos, e não em baht. Era o ideal? Claro que não. Sabíamos que não era o ideal? Sem dúvida. Foi isso que tornou possível o nosso lançamento global.

Uma lição rápida que retiramos do modelo simplificado foi que a geografia e a realidade dos pagamentos nem sempre coincidem da forma que se esperaria. Existe uma pequena ilha ao largo da costa do Canadá chamada São Pedro e Miquelão. No mapa, parece bastante canadiana. Na verdade, é um território francês, o que significa que lá se usa o euro. Descobrimos isto, claro, ao ver todas as transações nesse mercado falharem, porque a tratávamos como se fosse o Canadá — já que, geograficamente, parecia tão canadiana. Estávamos a utilizar dólares canadianos, e os sistemas de pagamento não estavam nada satisfeitos com isso. Quando se lança globalmente com estas suposições simplificadas, a realidade vai revelar esses casos-limite muito rapidamente, o que, claro, explica porque é que estávamos a acompanhar tudo de muito perto. Foi assim que descobrimos isto. Aquela ilha tem uma população de 6 000 pessoas. Tenho sérias dúvidas de que sequer metade delas tenha tentado inscrever-se na Netflix em 2016.

Estávamos atentos à situação. Do ponto de vista arquitetónico, esse atalho significava que os nossos sistemas de faturação e subscrição tinham de suportar clientes a serem faturados numa moeda que nem sempre correspondia ao seu mercado local, com preços que não estavam otimizados para a economia local. Tudo isto enquanto geríamos a nossa plataforma global de subscrições. Significava também que estávamos deliberadamente a lançar-nos em mercados onde sabíamos que a nossa cobertura de métodos de pagamento estava aquém do ideal. Aceitámos tudo isso. O nosso objetivo naquela altura não era a otimização perfeita. O nosso objetivo era lançar rapidamente, observar a procura real, aprender com a utilização real e, depois, dar prioridade a uma localização mais profunda nos mercados onde parecia que isso teria mais valor. Em vez de tentarmos acertar tudo antes do lançamento, lançámos com um modelo simplificado e depois aprendemos em produção, o que, quando se trabalha num sistema de grande dimensão, costuma ser uma forma bastante eficaz de aprender.

Uma das formas como acelerámos essa aprendizagem foi realizar experiências para compreender como os clientes realmente queriam pagar em cada mercado, porque nem sempre sabíamos. Fizemos algo chamado «teste da porta pintada», que é uma forma relativamente simples de medir o interesse. Funcionava da seguinte forma: quando os clientes chegavam à página de registo da Netflix, mostrávamos-lhes os métodos de pagamento suportados nesse mercado, que, na maioria dos casos, eram cartão de crédito e PayPal. Depois, mostrávamos-lhes os que achávamos que poderiam ser interessantes para aquele mercado específico, mas que, na verdade, ainda não tínhamos implementado. As pessoas clicavam nesse método de pagamento e recebiam uma mensagem que dizia algo como: «Obrigado pelo seu interesse, ainda não está disponível.» Depois, nos bastidores, registávamos esses cliques. Isso deu-nos dados reais sobre qual o método de pagamento que as pessoas realmente queriam utilizar. Este tornou-se o nosso principal indicador sobre o que localizar a seguir. Tratou-se de uma utilização muito deliberada da dívida técnica. Não foi acidental nem resultou de uma arquitetura descuidada. Foi uma dívida deliberada que assumimos para acelerar a nossa aprendizagem.

Pressuposto: Podemos armazenar credenciais de pagamento

Vamos agora para 2020. Todos se lembram de março de 2020, quando aconteceu algo muito grave. Estou a falar da regulamentação na Índia. O Banco Central da Índia emitiu uma diretiva que proibia os comerciantes de armazenar credenciais de cartões de crédito. Escolheram um momento excelente para o fazer: março de 2020. Isso significava não armazenar números de cartão de crédito, não armazenar datas de validade e nem mesmo os processadores de pagamentos ou adquirentes podiam armazenar essas informações; apenas as redes e os emissores de cartões podiam fazê-lo. Se opera um negócio de subscrições recorrentes que depende de dados de cartão de crédito, isso torna-se um problema. Claro que existe uma alternativa: a tokenização. É aqui que se troca um número de cartão com uma rede, que devolve um token, e depois pode-se usar esse token para efetuar os débitos mensalmente. É claro que o RBI só emitiu o quadro regulamentar de tokenização de cartões registados para a Índia em setembro de 2021, ou seja, um ano inteiro após a diretiva original.

O ecossistema na Índia não estava preparado para suportar isto. Tínhamos este prazo e dispúnhamos de recursos básicos que ainda não existiam. O prazo foi sendo adiado, como é habitual. Dezembro de 2021 passou a junho de 2022. Depois, finalmente, a regulamentação entrou em vigor em outubro de 2022. A regulamentação não afetou apenas o armazenamento; alterou fundamentalmente o funcionamento das cobranças recorrentes. Veja, na maior parte do mundo, o nosso sistema de faturação era bastante síncrono. Na altura da renovação, enviávamos uma cobrança a um processador e, em seguida, recebíamos o resultado. Às vezes demorava alguns dias, mas recebíamos um resultado. Atualizar o estado, simples. A Índia tornou esse modelo ilegal. Em vez disso, tivemos de adotar mandatos com montantes pré-aprovados. Um mandato é um conceito de faturação bastante simples. É apenas um utilizador que lhe concede a autorização para lhe cobrar de forma recorrente. O mandato indiano tem limites máximos de montante. Além disso, tem de incluir o 3DS.

O 3DS é o «Verified by Visa» ou o «Mastercard SecureCode», que já deve ter visto se utiliza cartões de crédito online. Trata-se de um passo de autenticação adicional. Normalmente, utiliza um código de acesso único enviado para o seu telemóvel ou, por vezes, redireciona para uma aplicação bancária. Isso comprova que o titular do cartão está efetivamente presente durante a transação. Na Índia, esta etapa é obrigatória para qualquer acordo de faturação recorrente. Uma vez que a regulamentação também introduziu limites máximos de montante, isso significava que, se tivéssemos de fazer uma alteração de preço, era necessária uma nova autorização. Se fosse uma atualização, era necessária uma nova autorização. Qualquer alteração exigia a interação do cliente. O próprio fluxo de cobrança também se tornou assíncrono. Antes de cada renovação, somos obrigados a enviar uma notificação de pré-débito com pelo menos 24 horas de antecedência. Isso dá ao consumidor a oportunidade de cancelar o faturamento recorrente, o que faz sentido. Só depois de a notificação ter sido recebida é que podemos efetivamente submeter a cobrança com base na referência da autorização. Isto alterou completamente o funcionamento do nosso sistema. Introduziu toda uma série de novos modos de falha, como a revogação da autorização, o excedimento do limite máximo, o termo da validade da autorização por parte do emissor — perguntem-me como é que eu sei — ou simplesmente o cliente optar por cancelar a assinatura.

Enquanto tentávamos encontrar uma solução que funcionasse para esta diretiva sobre o armazenamento de dados de cartões, o UPI, o sistema de transferências bancárias em tempo real da Índia, estava a crescer rapidamente. Adotámos o UPI Autopay. Era um método de pagamento adicional. É claro que o UPI tem exatamente os mesmos requisitos de mandato, consentimento explícito e também a notificação prévia de débito. As mesmas restrições arquitetónicas, apenas um canal de pagamento diferente, mas também traz a complexidade adicional de que o UPI não tem interoperabilidade entre adquirentes. Se criarmos uma autorização com um único adquirente, ficamos para sempre limitados a processar pagamentos através desse adquirente. Agora, estamos a lidar com autorizações, fluxos de trabalho de pré-débito, fluxos de confirmação assíncronos e uma infraestrutura de tokenização que ainda estava a ser construída. Lembre-se de que não estamos a fazer isto num produto novo. Já tínhamos milhões de clientes na Índia com pagamentos recorrentes por cartão de crédito. Não se tratava de criar algo novo. Tratava-se de migrar os utilizadores existentes, apagar as suas credenciais de pagamento, alterar os mecanismos de faturação e pagamento e, claro, evitar falhas na renovação, tudo ao mesmo tempo.

Este foi provavelmente o período menos tranquilo que tive enquanto trabalhei na Netflix. É claro que isso nos obrigou a repensar a nossa arquitetura. Tínhamos construído os nossos sistemas com base no pressuposto de que as credenciais armazenadas estavam disponíveis — um pressuposto bastante razoável — e de que podíamos efetuar o nosso faturação em tempo real. Agora, tínhamos de operar num mercado onde as credenciais não podiam ser armazenadas. As cobranças recorrentes exigiam uma autorização explícita com limites máximos de montante. Cada renovação exigia esta notificação prévia ao débito. Tivemos de fazer tudo isso no seio do nosso único sistema global de comércio porque, obviamente, não criámos uma arquitetura separada para a Índia. A regulamentação não se limita a aumentar a complexidade. Pode invalidar pressupostos fundamentais sobre o funcionamento do sistema. Quando esses pressupostos se quebram, tudo o que foi construído com base neles precisa de ser reconsiderado.

Sistemas Altamente Otimizados São Difíceis de Alterar

Estamos agora a chegar a 2021, creio eu. Pandemia. Durante a pandemia, aconteceram muitas coisas no setor. Tenho quase a certeza de que isso se deve ao facto de estarmos todos a trabalhar a partir de casa e termos tempo de sobra. Claro que, também no departamento de comércio da Netflix. Tínhamos uma grande iniciativa a que, internamente, chamávamos MHU (multi-household usage, ou utilização por vários agregados familiares). A imprensa referiu-se a ela como a «campanha contra a partilha de palavras-passe». Como parte desse esforço, introduzimos uma nova funcionalidade: a possibilidade de um assinante adquirir um lugar adicional para um membro na sua conta. Se fosse, por exemplo, um pai ou mãe com filhos em idade escolar, poderia pagar uma pequena taxa de subscrição adicional e permitir que eles utilizassem um login separado na mesma conta. Ora, isto parece muito simples? Sim, claro que não é simples. O desafio desta vez não era o fluxo de pagamentos. O membro adicional continua a utilizar as mesmas cobranças recorrentes no mesmo ciclo de faturação que a subscrição principal.

O desafio residia no modelo de relação. Pela primeira vez, precisávamos de começar a acompanhar a relação de faturação entre duas contas diferentes da Netflix: o pagador, que é o titular da conta, e o beneficiário, que utiliza a vaga. Até este momento, uma conta significava uma subscrição, o que significava um conjunto de direitos — claro e simples. Agora temos direitos derivados. O acesso do beneficiário à Netflix depende do estado da sua própria conta, mas também do estado de faturação de outra conta. Isto significou introduzir uma estrutura totalmente nova, a «assinatura adicional», como a chamámos. Uma entidade de faturação separada que coexiste com a assinatura principal, mas que pode ser gerida de forma independente. Claro que é essa independência que torna isto complexo. No modelo original, o estado de pagamento e o estado de acesso estavam intimamente ligados. Já abordei bastante este assunto. Se o pagamento falhar, o acesso cessa. Esta lógica é incrivelmente simples. Com o membro adicional, temos agora este gráfico de dependências.

Se a subscrição base do pagador falhar, todo o agregado familiar perde o acesso, incluindo o beneficiário. Se apenas a subscrição adicional falhar, apenas o beneficiário é afetado; o pagador continua a ter acesso ao streaming. E se o pagador fizer um downgrade do seu plano? O nosso plano premium permite duas vagas para membros adicionais, enquanto o plano padrão permite apenas uma. Um rebaixamento planeado pode forçar a cancelamento involuntário da subscrição do beneficiário. Estes são todos cenários que ainda não tínhamos. Tive de introduzir um novo estado de direito, eventos do ciclo de vida e uma nova lógica para lidar com estas dependências entre várias contas.

É claro que somos uma empresa incrivelmente orientada para os dados. Isto afetou a forma como medimos e monitorizamos o nosso sistema. O que me surpreendeu, pelo menos a mim, foi que as alterações aos nossos dados foram, na verdade, maiores do que as alterações ao sistema de comércio. As nossas métricas e painéis de controlo foram todos construídos em torno do comportamento de subscrição de uma única conta. De repente, passámos a ter contas associadas, em que o pagamento de uma pessoa podia desencadear alterações de estado numa conta completamente diferente. Isso alterou a forma como monitorizamos a rotatividade, como atribuímos receitas e, claro, como o serviço de apoio ao cliente lida com as escaladas. Obviamente, também tivemos de aperfeiçoar os nossos modelos de deteção de fraudes. Agora tínhamos de considerar padrões de abuso entre contas ligadas, e não apenas no âmbito de uma única subscrição. Não se tratava apenas de adicionar uma nova funcionalidade. Isso iria introduzir uma relação comercial com várias contas. Passava por um sistema que tinha sido concebido e otimizado para subscrições de conta única. Isto parece-me familiar. Não criámos um sistema separado para isto.

Incorporámo-lo na plataforma de subscrições existente, o que significava que todos estes novos comportamentos tinham de coexistir com um sistema que já operava à escala global. Nunca estávamos a projetar do zero. Estávamos a evoluir um sistema existente para suportar um modelo fundamentalmente diferente. Essa sobreposição de nova complexidade aos fluxos existentes é onde a dívida arquitetónica a longo prazo começa realmente a acumular-se. Lembram-se deste sistema? Em 2023, tinha-se transformado em cinco equipas, cada uma das quais responsável por vários domínios e a operar múltiplos serviços. Eu ia fazer um diagrama do sistema para mostrar como todos estes sistemas funcionam em conjunto, mas tenho quase a certeza de que isso é algo que nos ensinam a não fazer em apresentações. Podem imaginar que se parece mais ou menos com isto. Chega um ponto em que a complexidade de um sistema ultrapassa a capacidade das equipas de engenharia que o suportam. Demorámos mesmo muito tempo, demasiado tempo, a perceber que isso já tinha acontecido com a nossa equipa de pagamentos.

Na altura, tínhamos cerca de 14 engenheiros, todos subordinados a um único gestor, e isso, por si só, já era um sinal enorme. Havia um sinal ainda mais forte: a rotação de plantão. A rotação de plantão da equipa de pagamentos tornou-se tão stressante que os engenheiros decidiram encurtá-la da rotação habitual de sete dias para três dias e, depois, para quatro dias, apenas para torná-la suportável. Isso não é um bom sinal. Não é, de todo, um bom sinal. Quando isso acontece, temos de nos perguntar: será que o sistema é assim tão instável? Estará tão cheio de bugs, ou será simplesmente demasiado complexo para a equipa que lhe dá suporte? No nosso caso, não era o facto de o sistema estar cheio de bugs. Tinha os seus problemas, como qualquer sistema. O que se passava era que já nenhum engenheiro conseguia abranger toda a sua complexidade na sua cabeça. A nossa primeira resposta foi de natureza organizacional.

Dividimo-nos em equipas. Criámos uma equipa focada no produto, outra em ferramentas/operacionalidade e, por fim, uma equipa de plataforma a trabalhar na arquitetura subjacente. Em retrospetiva — como sempre, a visão retrospectiva é perfeita —, percebi que isto é um antipadrão. Quando se tem uma equipa de plataforma a dar suporte a uma única equipa de produto nesta relação de um para um, duas coisas acontecem. Primeiro, os engenheiros de plataforma perdem o contacto com a forma como a sua plataforma é realmente utilizada. Segundo, os engenheiros de produto perdem a responsabilidade pela arquitetura subjacente. Isso cria uma separação, mas não reduz a complexidade. Embora isso tenha ajudado temporariamente, na verdade não resolveu o problema de raiz.

Começámos a decompor o monólito. Algumas das divisões foram bastante simples. Por exemplo, o nosso método de armazenamento de pagamentos, o armazenamento MOP, tornou-se um serviço independente. Isto permitiu-nos dimensioná-lo de forma diferente para diferentes cargas de trabalho. Os fluxos de registo e de utilizadores em tempo real têm características de escalabilidade muito diferentes em comparação com o processamento em lote e as renovações. Atender a ambos a partir do mesmo ambiente de execução significava que estavam a competir pelos mesmos recursos. A separação reduziu esse conflito operacional. Outra extração que realizámos foi o nosso motor de regras de negócio. O encaminhamento de pagamentos, ao longo dos anos, tornou-se muito complexo. Temos tendência a ter vários processadores para um único método de pagamento em cada mercado, principalmente por uma questão de redundância. Introduzimos uma interface de utilizador para que a equipa de operações pudesse modificar estas regras de encaminhamento sem envolver os engenheiros. Por fim, incorporámos o aprendizado automático para simplificar as decisões de encaminhamento. Esta camada de encaminhamento podia agora combinar regras estáticas com experimentação A/B e aprendizado automático. Isso funcionou bem, tecnicamente.

Na verdade, não reduziu a carga cognitiva da equipa. Os engenheiros continuavam a ter de compreender como tudo isto se encaixava. Foi então que percebemos que o problema não eram os limites dos serviços, mas sim os limites dos domínios. Mesmo que se separem partes do monólito, se uma equipa continuar a ser responsável pelo todo, cada engenheiro tem de compreender a maior parte do sistema. Fizemos uma pergunta diferente. Como podemos reduzir a complexidade do sistema para que qualquer engenheiro consiga compreender a maior parte do mesmo? Foi então que decidimos dividir o sistema e a equipa por domínio. Separámos-o em duas áreas principais. Uma centrava-se nos fluxos de trabalho voltados para o consumidor, como registos, adição e gestão de métodos de pagamento e gatilhos de pagamento baseados em direitos. A outra centrava-se exclusivamente no processamento de pagamentos, na lógica de encaminhamento, nas integrações com fornecedores, nas otimizações e no ciclo de vida dos movimentos de dinheiro. Dois domínios de problemas muito diferentes. Um diz respeito às interações com o utilizador e às transições de estado, e o outro à infraestrutura financeira, ao ecossistema de fornecedores e aos movimentos de dinheiro.

A divisão ao longo dessa fronteira permitiu que cada equipa fosse responsável por um domínio coerente. Esta não foi uma divisão nítida. Em alguns casos, a integração de um método de pagamento e o subsequente processamento desse método exigem a integração com o mesmo fornecedor. Tomemos o PayPal, por exemplo. A criação de um acordo de faturação ocorre durante a integração. Trata-se de uma API diferente da API de cobrança utilizada durante as renovações de subscrições, mas é a mesma integração com o fornecedor. Em vez de criarmos um componente de integração partilhado entre os dois novos sistemas, tomámos a decisão deliberada de duplicar o código de integração. Não foi por ser uma solução arquitetonicamente elegante, mas porque permite que cada equipa avance de forma independente e nos permite concretizar a separação muito mais rapidamente. Também conferiu a cada equipa a responsabilidade de ponta a ponta pelo fluxo de trabalho que tem de suportar. Introduzimos esta duplicação e é possível que, mais tarde, venhamos a reverter parte dela. Já há conversas a esse respeito. De momento, este custo do acoplamento partilhado era superior ao custo da duplicação.

Claro que, mais uma vez, tudo isto estava a acontecer enquanto estávamos a implementar novos métodos de pagamento, a integrar novos processadores e a lançar modelos de comércio totalmente novos. Não foi uma reescrita limpa. Foi, como as pessoas gostam de dizer, trocar as rodas de um autocarro enquanto este circula na autoestrada a 60 milhas por hora. A lição fundamental para mim aqui foi esta. Por vezes, a complexidade não requer melhores abstrações. Requer limites claros de responsabilidade. Por vezes, a duplicação é mais barata do que a coordenação. Esta foi outra escolha deliberada.

Tudo, em todo o lado, ao mesmo tempo

Justamente quando estamos a passar por esta reestruturação plurianual do sistema de pagamentos — na verdade, bem no meio dela —, em 2024, acontece outra coisa. A Netflix decide entrar no mercado dos eventos ao vivo. Estamos a planear transmitir os jogos de Natal da NFL, que prevemos que venham a ser um dos maiores eventos que alguma vez tivemos de suportar. De repente, toda a empresa entra neste modo de «todos a postos». No que diz respeito ao comércio, isto deve-se ao facto de introduzir um padrão de registo completamente novo, diferente de tudo com que já tivemos de lidar anteriormente. Até este momento, o crescimento das subscrições tem sido incrivelmente previsível. Sabíamos onde os principais conteúdos seriam lançados porque, claro, éramos nós a lançá-los. Sabíamos como as inscrições poderiam aumentar ao longo dos fusos horários. A nível global, o tráfego comportava-se como uma onda contínua, em que as regiões acordavam e, depois, outras adormeciam. Essa previsibilidade torna tudo muito mais fácil. Temos aqui o nosso planeamento de capacidade, o autoescalonamento, a deteção de fraudes e o encaminhamento de processadores.

Tudo se baseia neste modelo previsível. Os nossos modelos de deteção de fraudes também foram treinados para reconhecer o que era considerado normal. Os sistemas estavam muito bem ajustados à procura cíclica. É claro que os eventos ao vivo quebram esse padrão. Num grande evento ao vivo, pode ocorrer um pico massivo de inscrições legítimas concentradas num período de tempo muito curto numa única região. Para um sistema de deteção de fraudes que foi treinado com base no nosso uso cíclico, isso parece exatamente uma fraude. Agora temos de nos perguntar: o que fazemos? O que acontece se os nossos sistemas de deteção de fraudes começarem a bloquear clientes legítimos logo no início do evento? Também temos de pensar de forma diferente sobre o nosso planeamento de capacidade. Temos capacidade de processamento suficiente para picos de inscrições? Os nossos processadores de pagamentos têm margem de manobra suficiente? O que acontece se uma região inteira ficar sobrecarregada? Uma das principais alterações que implementámos foi a divisão da capacidade de processamento entre fluxos de trabalho em lote e tráfego de inscrições em tempo real.

O processamento em lote, como renovações e liquidações, oferece flexibilidade. Se faturarmos os nossos clientes uma hora mais tarde do que o habitual, ninguém se vai queixar. Se alguém não conseguir inscrever-se no meio de um evento ao vivo com grande afluência, as pessoas dão por isso. Concebemos o sistema de forma a que o tráfego de registos tenha prioridade, as políticas de escalabilidade sejam significativamente mais agressivas e, se for necessário, possamos redirecionar capacidade dos nossos sistemas de processamento em lote. Também introduzimos algumas estratégias explícitas de «fail open». Analisámos o nosso percurso de registo e procurámos pontos de falha. Assim, se um sistema antifraude ficar sobrecarregado ou se tornar excessivamente agressivo — algo que esperamos que aconteça —, podemos continuar a recolher sinais, mas permitimos que as inscrições ocorram e apenas analisamos os resultados mais tarde. Se um processador de pagamentos numa determinada região ficar sobrecarregado, podemos sempre redirecionar para outro processador. Num cenário extremo, em que todo o sistema de pagamentos fica inoperacional, podemos sempre permitir a entrada das pessoas e tentar cobrar o dinheiro mais tarde. Porque, durante um evento ao vivo, a prioridade é deixar entrar os clientes legítimos. A reconciliação financeira pode sempre ser feita mais tarde. Não é possível repetir um momento ao vivo se alguém não o tiver podido ver em tempo real.

Depois de toda esta preparação, pensámos que o que tínhamos seria um evento-teste bastante bom: o combate entre o Jake Paul e o Mike Tyson. Alguém aqui assistiu? Foi um grande acontecimento nos EUA. Originalmente, estava agendado para julho. Tratámos isso internamente como o nosso ensaio em grande escala para os jogos da NFL. Realizar um grande evento, ver o que falha, corrigir antes do Natal. Claro que não aconteceu em julho. Foi adiado para novembro, o que, obviamente, nos deu mais tempo para nos prepararmos, o que é bom, mas também significou que tínhamos muito pouco tempo para corrigir qualquer problema grave que descobríssemos antes dos jogos da NFL na época do Natal. Os níveis de stress subiram um pouco. Chegou a data do combate e estávamos todos a observar os painéis de controlo, a acompanhar a situação pela manhã, para ver como as coisas estavam a correr. Ao meio-dia, já tínhamos excedido as inscrições previstas para todo o evento, e o evento era às 20h.

Nessa altura, olhámos uns para os outros e pensámos: sim, isto vai ser algo em grande. Tornou-se uma situação em que todos tiveram de dar o seu melhor. Toda a gente estava a observar os painéis de controlo. Todos prontos para reagir. Devo dizer que os sistemas de inscrições e de comércio funcionaram muito bem. Este é o gráfico real das inscrições desse evento. As cores representam apenas as diferentes fases do combate de boxe. A escalabilidade comportou-se exatamente como esperávamos. Não houve gargalos inesperados. A título de referência, aquela pequena cauda no final corresponde ao nosso tráfego habitual de inscrições. Não sei se posso dizer o mesmo em relação à parte do streaming. Houve alguns recargas, e isto daria muito mais motivo para risos se todos tivessem realmente assistido ao combate de boxe. Tivemos muitas recargas. Foi um evento que bateu recordes em mais do que um sentido. Do ponto de vista do comércio e das inscrições, foi exatamente o teste de resistência de que precisávamos.

Validou as decisões arquitetónicas que separavam a capacidade, as nossas políticas de escalabilidade agressivas e as estratégias claras de «fail open», que, felizmente, não tivemos de utilizar, mas que tínhamos na manga. Quando chegaram os jogos da NFL, já tínhamos visto o que acontece quando um público verdadeiramente global tenta inscrever-se tudo ao mesmo tempo. Mais uma vez, o sistema não chegou a esse ponto através de uma reformulação completa. Chegou lá através de uma longa série de compromissos deliberados. Durante uma década, «correto» na Netflix significava cobrar antes de conceder acesso e sinalizar padrões invulgares. Durante o evento ao vivo, «correto» passou a significar: deixar entrar primeiro os clientes legítimos, reconciliar mais tarde; a análise de fraudes pode esperar.

Conclusões

À primeira vista, todas estas histórias parecem diferentes. Mercados diferentes, restrições diferentes, modelos de negócio diferentes, mas, para mim, todas revelam a mesma coisa. A arquitetura codifica pressupostos, e a realidade acabará por quebrá-los. A expansão na América Latina ensinou-nos realmente que construímos a nossa arquitetura em torno do comportamento do nosso primeiro mercado, e que o mundo não se comportava da mesma forma. O lançamento global foi um exemplo de como nem toda a dívida é acidental. Parte dela é estratégica. Devido às alterações regulamentares na Índia, aprendemos que as credenciais armazenadas não eram uma garantia, mas sim um privilégio. Quando chegou a altura de implementar o MHU (utilização por vários agregados familiares) e adicionar a funcionalidade de membros adicionais, descobrimos que a plataforma de subscrição altamente otimizada e simplificada em que o nosso sistema se tinha tornado acabou por funcionar contra nós. Percebemos que os sistemas não atingem apenas limites técnicos. Atingem também limites cognitivos. Por vezes, a arquitetura tem de mudar para permitir o crescimento das equipas, e não apenas do próprio sistema. Por fim, quando os padrões de utilização mudam, a definição do que é «correto» também pode mudar. Para terminar, tentei encontrar uma boa citação para colocar no ecrã que captasse um pouco disto, mas não consegui, por isso terá de servir esta: «Os grandes sistemas não sobrevivem porque foram perfeitamente concebidos. Sobrevivem porque continuam a evoluir à medida que a realidade muda.»

Perguntas e Respostas

Participante 1: Na Netflix, tornou-se agora uma prática manter o sistema aberto a extensões, devido a todo o conhecimento adquirido ao longo da década? Trata-se de uma prática, de um princípio, ou agora têm em conta estes aspetos ao conceber um sistema?

Kasia Trapszo: O que é interessante na Netflix é que, quando comecei lá, há 11 anos, éramos mais como adolescentes no que dizia respeito a sistemas. Estávamos a construir coisas rapidamente. Agíamos como uma startup. Só precisávamos de lançar, lançar, lançar. Não estávamos a conceber as coisas a longo prazo. Agora, estamos mais numa fase de «adultez desajeitada», em que temos de começar a manter estes sistemas que construímos ao longo dos anos. Agora, estamos mais focados numa boa arquitetura, no escalonamento e em garantir que as coisas realmente fazem sentido. Na verdade, estamos a fazer bastantes reescritas destes sistemas mais antigos.

Participante 2: Falaste sobre como distribuíste a carga para que os sistemas em lote pudessem ser utilizados pelos sistemas em tempo real. Obviamente, são padrões de processamento muito diferentes. Como conseguiste fazer isso? Tratou-se apenas de um recurso de CPU, ou houve mais do que isso?

Kasia Trapszo: Trata-se, na verdade, apenas de capacidade na nuvem. Durante estes grandes eventos ao vivo, fazemos um pré-dimensionamento dos nossos sistemas; quando surge uma grande carga de inscrições ou uma grande carga de streaming, queremos garantir que tudo esteja pré-dimensionado. Não nos limitamos a dedicar tempo a dimensionar tudo para cima e a lançar aplicações. Na verdade, por vezes deparamo-nos com problemas de capacidade em algumas regiões. Para resolver isso, se a carga for realmente muito grande, temos todo um plano de contingência que indica quais são os sistemas que podem ser desligados com segurança, e podemos aproveitar essa capacidade para a alocar a outros sistemas.

Participante 3: Como é que tomaram a decisão de escalar globalmente e de recorrer a fornecedores em vez de desenvolver internamente? Como é que a equipa tomou a decisão de distribuir a aplicação pelas equipas e como é que executaram isso?

Kasia Trapszo: Quanto à primeira parte, isso ultrapassa as minhas competências, porque sou engenheira. Muitas dessas decisões são tomadas ao nível da liderança. Especialmente na altura do lançamento global, eu era apenas uma engenheira sénior na equipa de pagamentos. Agora ocupo uma posição mais de liderança, mas não teria estado envolvida nessas decisões. Estava mais envolvida na arquitetura, do ponto de vista da equipa. Estava profundamente envolvida nesse aspeto. Simplesmente percebemos que os engenheiros tinham uma carga cognitiva enorme e que era incrivelmente stressante para eles darem suporte ao sistema. Tornou-se simplesmente demasiado. Especialmente a rotação de plantão, que foi um sinal muito claro. Quando os engenheiros vêm ter contigo e dizem: «Ouve, estou de plantão há três dias e tenho sido chamado todas as noites. Não consigo dormir.

Estou tão esgotado. Não quero estar de plantão outra vez.» É nesse momento que se deve reavaliar a situação. A primeira coisa a analisar é: por que razão a estabilidade do sistema é tão fraca? Se a estabilidade do sistema for, na verdade, razoável, mas se tratar apenas de um sistema muito complexo, então é aí que se tem de começar a pensar em como dividir esta besta complexa em algo mais pequeno e mais gerível?

Participante 4: Mencionou que dividiu as equipas em equipas focadas no produto e equipas mais orientadas para a plataforma. No que diz respeito ao suporte a novos métodos de pagamento — e tenho a certeza de que provavelmente suportam centenas em todo o mundo —, como é que as equipas, por exemplo, que atuam num determinado mercado, gerem a responsabilidade pela integração básica dos métodos de pagamento? Digamos que um determinado método de pagamento tenha novas capacidades que a plataforma nunca tinha previsto; como é que faz para que estas equipas interajam? Será que uma equipa de plataforma se torna um estrangulamento na integração dessa nova funcionalidade em toda a superfície da API? Estou realmente curioso para saber a sua opinião sobre como organizou isso.

Kasia Trapszo: Esse era o modelo que tínhamos no início: uma equipa de plataforma e, depois, uma equipa de produto. Uma das dificuldades com que nos deparámos foi o facto de isso atrasar o processo. Além disso, as pessoas já não têm o mesmo nível de responsabilidade que tinham antes, mas continuam a ter de lidar com a mesma complexidade. Abandonámos esse modelo bastante rapidamente. Acho que demorámos alguns anos a perceber que este era um mau modelo. Depois, passámos a uma divisão baseada em domínios, em que o processamento de pagamentos é um domínio e a integração de novos utilizadores e os fluxos de trabalho baseados no utilizador constituem outro domínio. Se estivermos a integrar um novo método de pagamento que tenha componentes sob a responsabilidade de ambas as equipas, envolvemos ambas as equipas no projeto. Na Netflix, somos uma equipa vertical bastante grande no que diz respeito aos pagamentos, por isso também temos equipas de interface do utilizador (UI) e uma camada intermédia que faz a ligação entre a UI e o backend, pelo que essas equipas também estão envolvidas. Temos tendência a ter estas equipas de projeto verticais que se envolvem no processo de ponta a ponta.

Participante 5: Como é que equilibram a dívida técnica com as novas funcionalidades necessárias para expandir o território? Costumam implementar primeiro uma solução tática e só depois pensar numa solução mais estratégica? Surpreende-me que nunca tenham mencionado a IA em toda a sessão. É precisamente este tipo de design de arquitetura à moda antiga, próprio de engenheiros de software, que procuramos. Quero perguntar-lhe: acha que a IA vai resolver esta complexidade arquitetónica, a dívida técnica e todas essas questões?

Kasia Trapszo: A questão da IA… na verdade, esse era o meu objetivo, só que não sei quantos de vocês repararam que um dos slides tinha um braço comprido com um aspeto realmente estranho. Não consegui que o ChatGPT corrigisse isso. A IA foi utilizada para criar esta apresentação, mas não foi mencionada.

Dívida técnica versus novas funcionalidades, sim, o eterno problema. Não há uma boa resposta para essa pergunta. Depende realmente do que se prioriza. O que é mais importante para si neste momento? É lançar o produto ou ter uma arquitetura limpa que terá de manter durante vários anos? É preciso priorizar o que é importante para si em cada momento, porque a resposta nunca é a mesma.

Participante 5: Achas que a IA vai resolver esses problemas por nós?

Kasia Trapszo: Não por enquanto. Eu utilizo bastante a IA. Todos nós na Netflix o fazemos. É muito bem suportada. Mas ainda não está preparada para lidar com estes problemas grandes e complexos. Talvez um dia no futuro, mas sim, acho que precisamos desses seres humanos.

Participante 6: Disse que, quando começou, eram 14 pessoas a trabalhar na área dos pagamentos. Quantas pessoas trabalham agora?

Kasia Trapszo: Neste momento, a equipa de pagamentos é composta por 35 engenheiros, creio eu. Quando comecei, eram 7 engenheiros. Eram 14 quando decidimos dividir as equipas.

Veja mais apresentações com transcrições