Show! Galera, estamos começando mais, oficialmente, mais esse encontro, tá? Somente para vocês entenderem como é que vai ser a dinâmica hoje aqui, tá? Nós vamos ter duas partes desse nosso encontro. A primeira parte é onde eu quero trazer algum case para a gente discutir sobre alguns assuntos que são importantes para a gente que é desenvolver a aplicação crítica, tá? A segunda parte, a gente vai seguir com a mesma linha que a gente fez no último encontro a gente vai fazer um hot seat ou seja, a gente vai pegar todo mundo que está aqui quebrar em salas de 5 pessoas e vocês vão ter, cada pessoa vai poder tirar uma dúvida, onde essa dúvida os amigos dessa sala podem discutir isso com eles cada pessoa vai ter 10 minutos pra rodar a sua dúvida. Depois disso, volta pra sala de novo e começa a rodar a outra pessoa pergunta. Na hora que chegar nessa parte, pra quem não entendeu direito o que eu falei agora, eu vou explicar com mais calma. A gente explica com mais calma, beleza? Pessoal, seguinte, hoje o tema que eu vou trazer aqui, ele é polêmico e eu tenho estudado bastante isso nesses últimos dias, tá? E ele envolve claramente arquitetura de solução, a gente falou sobre system design e a gente falou sobre fundamentos de arquitetura de software. A gente está evoluindo agora para patterns e tudo mais, mas eu acho que o principal ponto que eu quero trazer aqui com vocês é sobre escalabilidade. A minha pergunta que eu trago aqui pra vocês inicialmente é vocês acham que toda vez que eu crio um sistema, esse sistema, ele tem que conseguir escalar horizontalmente? Não. Depende. Depende? Me dá um exemplo. Então, me fala um exemplo. Me fala um exemplo que um sistema em produção que você vai rodar e que ele não deve escalar horizontalmente. É um sistema que... O sistema que é uma prova de conceito. Não, não. Estou dizendo um sistema produtivo. Está rodando milhões de transações ali, alto tráfego, concorrência. Esse Joaquim não dá para esse... E aí, todos esses sistemas precisam escalar horizontalmente? Dependendo da geração de oportunidade. As transações têm que escalar, né? Eu estava pensando em um sistema pequeno de uma empresa pequena pra uso interno, tá, não precisa escalar. Não, vamos pensar um sistema ali que tá recebendo ali pô, um milhão de requisições por segundo. Não tem como, tem que escalar mesmo. Tem que escalar? Tem alguma coisa do tipo, ele vai ter que, vamos dizer que uma instância dele, conta de, sei lá, 5 milhões. Eu fiz uns testes ali, uma instância dá conta de 5 milhões. E sabes que em produção é, tipo, impossível, não vamos dizer impossível, mas assim, pela regra do negócio, ela jamais passaria de 2 milhões e por acaso está em 1 milhão de requisições. Nesse caso, talvez não precisasse escalar. Eu vou trazer um case aqui para vocês, para a gente discutir algumas situações aqui para vocês pensarem aqui comigo. E vocês vão saber de onde eu trouxe isso. A gente vai ter, ter inclusive um próximo evento que a gente vai fazer e a gente está desenvolvendo um sistema desse tipo de evento eu comecei a estudar bastante isso com algumas pessoas e eu falei esse caso ele é bem interessante deixa eu colocar aqui escalabilidade bolsa eu vou compartilhar minha tela aqui para que vocês consigam ver aqui estão vendo aí minha tela, né? estou vendo perfeito, então o lance é o seguinte galera a gente tem um desafio hoje que eu quero que vocês me ajudem a pensar a alto nível como que eu quero que vocês me ajudem a pensar a alto nível como que eu consigo desenhar um sistema desse tipo. E o sistema, de forma geral, ele é um sistema de bolsa de valores. Todo mundo sabe como é que funciona a bolsa de valores? Sim ou não? Quem não sabe como é que funciona? Eu não sei. funciona? Eu não sei Oi? Eu não sei Tá, então vamos lá Eu vou explicar aqui pra vocês A ideia de como que a coisa funciona Tá? Mas funciona o seguinte Eu tenho Dois livros Tá? Vocês estão vendo bem a minha tela aí? Sim, sim tenho dois livros. Vocês estão vendo bem a minha tela aí? Ou acho que o Alessander está com um barulho aí no fundo, se puder tirar só para não ficar clichadão. Então, o lance é o seguinte, eu tenho dois livros. E esse livro é o seguinte, eu tenho uma parte que é onde eu tenho pessoas que querem comprar ações e eu quero pessoas que querem comprar ações e eu quero pessoas que querem vender ações tá? então o que que eu posso falar? eu posso chegar aqui e falar, olha o Wesley foi eu botando meu nome com dois L's o Wesley quer comprar a ação da da meu nome com dois L's. Wesley quer comprar a ação da... da... Pegue. Eu ia falar... Da Full Cycle. A ação da Full Cycle. Tá? Se Deus quiser a gente faz o nosso IPO um dia. Quero comprar a ação da Full Cycle por 20 reais. Tá? E quero comprar a ação da Full Cycle por R$ 20,00. E aparece que o meu amigo Olimpio quer vender a ação da Full Cycle por R$ 19,00. Ok? O que a bolsa faz no final do dia? ela pega pessoas que estão interessadas em comprar de pessoas que estão interessadas em vender aí se isso aqui deu certo, dá um match o que que acontece? ele gera uma transação e essa transação fala Wesley comprou, sei lá, 10 ações a 19 reais do Olimpio. Aí, essa ordem de compra de venda do Olimpio é fechada, ou seja, eu dou um close nela, e a do Wesley também é fechada, porque ela conseguiu dar. Tem situações que você compra parcialmente, então você tem várias transações, o Olimpio quer vender 19, eu quero comprar 20, e daí tem outra pessoa querendo vender 1, então eu compro de duas pessoas diferentes. Tudo bem, eu quero que 20 e daí tem outra pessoa querendo vender um, então eu compro de duas pessoas diferentes. Tudo bem, eu quero que vocês entendam essa ideia básica aqui. O grande ponto é que, num sistema crítico desse tipo, nós temos milhões de requisições acontecendo por segundo. Tá? E a minha questão aqui é como que eu consigo escalar um sistema nesse molde? Wesley, se eu puder dar um input aí, hoje eu trabalho na Bradesco Seguros e na Bradesco Banco, né? E o que a gente tem lá? A gente tem o SAP, que não é um sistema que escala horizontalmente por natureza. E, além disso, a gente tem um cenário online em sistemas antigos. Então, hoje a gente tem Pix, a gente tem um monte de ocorrências online, mas o nosso parque tecnológico é mais antigo. Então, como que a gente trabalha? A gente costuma escalar verticalmente, sempre que necessário, mas a gente tem na frente o mesmo sistema que, por acaso, o mesmo sistema da Bolsa de Valores, que é o Data Power, ele funciona como uma fila, e aí ele é o cara que fica recebendo as rajadas. E esse cara, lá não escala por uma decisão deles, eles têm muito hardware, mas poderia ser cloud, por exemplo, e esse cara vai enfileirando. E essa fila, ela vai sendo consumida pelos sistemas mais frágeis, vamos dizer assim, à medida que os sistemas aguentam. Então, eu não escalei o sistema que está, de fato, precisando dar consistência, o sistema que está, de fato, precisando efetuar a transação. Mas eu escalei a recepção daquela rajada e isso acontece muito rápido, né? Parece que vai ser uma coisa lenta, mas isso acontece em frações de segundos ali. É muito rápido. Bom, vamos lá. Então, tem alguma coisa importante pra gente falar aqui. A gente precisa no final das contas de uma entrada, tá? Que pode ser uma fila aqui. Vamos colocar basicão aqui, ó. Kafka, tá? Aguenta. Usa-se muito também. Pra caramba aqui, ó. Ele entra, o... Esse cara aqui manda dado pra cá, esse cara consolida a transação e ele tem que ter uma saída aqui também que pode ser o cá fica aqui também publicando a transação que tá acontecendo aqui beleza agora a minha questão é aqui ó esse sistema aqui tá esse sistema aqui onde tem a minha lógica de negócios, que faz esse match de ação de compra e de venda, como eu escalo esse sistema? Essa aí está a grande questão. Eu quero que vocês, de cara, pensem aqui comigo. Qual é o principal vilão, nesse nosso caso, para a gente conseguir escalar esse sistema horizontalmente? Eu diria consistência. Consistência, né? A gente tem muita coisa concorrente rodando, você vai ter um banco de dados, né? E daí, se eu tenho dois sistemas desse e esses caras concorrendo pelos mesmos registros do banco de dados, eu vou ter um problema gigante, né? Eu vou ter que ficar fazendo lock no meu banco de dados o tempo inteiro para eu conseguir fazer esses matches. Então, como que eu escalo esse cara? Você pode trabalhar com um lock otimista nesse caso aí, né? Mesmo assim, milhões de registro, cara. Milhões. Um banco de dados vai abrir o bico. Pode ser o banco de dados que for. Pode estar trabalhando com um lock otimista aí. Se a gente começasse quebrando isso, porque aqui está como uma ação como um todo, né? Mas normalmente o match vai ter que acontecer pelo tipo de ação. Vamos dizer, tem as ações da FullSci, com as da Microsoft, da Apple, daria para ter uma instância, a princípio, uma quebra inicial, instâncias separadas para cada ação. Para o shared, né? Isso, e aí daria para também pegar, e a própria, vamos dizer, os dois books ali, os dois livros, E a própria, vamos dizer, os dois books ali, os dois livros, também daria para ser quebrado por uma parte que fica em memória, que seria a parte mais próxima da parte, como é que eu vou dizer, do preço atual da ação, digamos assim, que é onde provavelmente vão acontecer a maioria das transações, e uma segunda parte para quando alguém foi lá e pediu uma quantidade muito grande de ação que vai acabar exigindo muitos vendedores ou coisa assim. Então, que tivesse o complemento desse livro, sabe? Uma parte que possivelmente seria mais lenta, mas ela trabalharia com essa continuação do livro. Então, vamos lá. Primeira coisa que você está falando, isso aqui é interessante. Primeira coisa que ele está falando aqui é, eu posso duplicar, escalar esse sistema horizontalmente num formato de sharing aqui baseado no tipo de ação. É isso, né? Então aqui eu só vou movimentar Petrobras. Aqui eu só vou movimentar Petrobras. Aqui eu só vou movimentar Full Cycle. E aí tem um tópico para cada ação? Chegando? Ou todo mundo lê o tópico de todo mundo? Eu não pensei nessa parte. Eu pensei só na parte aqui do sistema. Não, não. Eu pensei que era para concentrar no negócio aqui. Aí ali eu... Eu pensei que era pra Concentrar no negócio aqui Não, é que como duplicou A gente tem que pensar no input, da onde que vem o input dele Se o Kafka aguentasse Como o Kafka pode Aguentar uma quantidade muito grande Poderia vir de uma outra Fila, um outro tópico Poderia ser do mesmo, da outra É bom de um só, porque você não tem que ficar fazendo O if e filtrando Os caras que você não quer. Galera, quem concorda que dá pra fazer algo desse tipo com o que o Gustavo tá falando? Concordo. Pode levantar a mão? Pode falar, galera, não precisa levantar a mão. Eu concordo. Concordo. Eu acho que tem uma perda muito grande ali. Então, eu ia falar uma coisa aqui. Eu acho que só... Estou pensando em contexto, né? Eu não estou pensando em tecnologia, mas eu acho que eu entendi seu ponto. A gente vai escalar e a gente não pode simplesmente distribuir loucamente uma ideia de contexto aí e tudo que está dentro do contexto vai ficar, vamos dizer assim, sincronizado, e quando o contexto é diferente, eles são independentes e aí a gente aplica a escalabilidade de forma horizontal. Me dá um exemplo prático, cara, eu não entendi nada que você falou. No caso, a ação. Ele falou da ação, ou seja, uma ação não pode interferir na outra. Então já seria uma forma de separação. Eu acho que no caso, quem está querendo negociar a ação da Petrobras precisa ter acesso a todo o registro de ofertas, de compra e de venda da Petrobras. Exato. Mas a ação, de venda da Petrobras. Exato. Mas a ação, por exemplo, da VAG não interfere. Então, quem está negociando VAG não está competindo com quem está negociando Petrobras. Então, vamos fazer isso. Só um ponto. Isso aí não poderia desbalancear cada serviço, uns com muitos, outros com poucos, com muito pouco. Tem robôzinho da Oi, por exemplo, que ficava o dia todo batendo lá, vendendo, comprando o dia todo. E tinha ação que você tinha 10 movimentações por dia. Então, você ia ter uma máquina atuando o dia todo. Fazer um 80-20, separar as principais mais movimentadas, duplicando o sistema. E as outras 80% que tem pouca movimentação, sei lá, roda na mesma máquina, por exemplo. Mas você também não tem garantia. Quem garante que não vai subir um robozinho de alguém e fazer uma alavancada em uma ação e subir do nada? Do dia para a noite. Tem ação que faz isso, né? O pessoal chama dos micos da bolsa, né? Do dia para a noite noite ela sobe 300 vezes o preço dela, porque alguém começa a comprar que nem louco, negociar, uma casa de recomendação, recomendou, o pessoal sai uma notícia no jornal, o mundo sai vendendo. Da Americanas lá... Deu o rolo da Americanas, por exemplo. Todo mundo sai vendendo. Não permite fazer algo semelhante que existe com Bitcoin, fazer pacotes de persistência? Tá, mas eu acho que mesmo uma rajada, se ele ficar, o Kafka vai garantir a ordem. Beleza, recebi uma rajada que eu não estava esperando. Mas isso não derrubou meu sistema, não aconteceu nada. Eu só vou ter que aumentar ali, talvez, a parte vertical ali de compra e venda, mas está no Kafka. Enquanto eu vou e aumento meu hardware verticalmente aqui, para aquela ação que antes eu estava dando um hardware menor, está tudo no Kafka. Uma coisa que eu me lembro da Bolsa de Valores é que um dos objetivos deles era o tempo de resposta. Eles tinham que ter um tempo de resposta extremamente rápido, milissegundos, tanto que eles fizeram código para processar nem pela memória, processavam uma camada do processador e usavam mais processador que tudo justamente para poder fazer a expressão em fase instantânea. Na hora que eu vou comprar uma ação, o valor daquele ativo é baseado no valor da última transação que aconteceu, então, se eu estou olhando lá, Petrobras a 10 reais, está 10 reais, porque a última transação que aconteceu foi a 10, mas por que ela fica mudando o tempo inteiro? Porque está tendo um monte de transação, um monte de compra e venda ali em cima daquele ativo. Mas eu vou fazer uma pergunta ainda. É que a gente está para usar na consulta, né? Vamos imaginar que a gente vai pegar aqui a ideia do Gustavo e falou, porra, ótimo, então agora aqui a gente só vai transacionar um tipo de ativo. Só vou transacionar aqui a ação da Full Cycle e beleza. só vou transacionar aqui a ação da full cycle e beleza mesmo assim cesso pra caramba aqui, eu consigo escalar esse cara horizontalmente esse cara é mais complicado aí eu acho que viria aquela segunda ideia de quebrar o tamanho do book aqui deixar o book prioritário com as ações mais próximas do preço de mercado. Cara, o lance é o seguinte, né? Você tem que vender de acordo com a ordem de chegada. Você não pode falar que tem um book mais prioritário ou menos prioritário, entendeu? Sim, então, mas pensando ali no book, o book vai ter a ordem dele vai ser o valor mais próximo do valor de mercado e depois o pessoal, pô, eu quero comprar, mas eu vou comprar, eu tô disposto a pagar só 10 reais e tá todo mundo vendendo e você tá fazendo isso que vai me ajudar com o algoritmo isso, aí vai jogar lá pro final digamos assim mas mesmo assim, isso eu precisar escalar. Tudo isso você está fazendo, mas é muita requisição. Como é que você escala esse cara? Primeira coisa, você vai guardar isso no banco de dados? Qual banco de dados vai guardar esse seu book? De repente um cache em memória, Acho que de repente um cache em memória Com estratégia De ter um tempo Para morrer essas informações do cache Que as pessoas precisam Não pode morrer informação do cache Não, mas aí elas precisam Elas precisam Das últimas transações até um certo ponto A partir de transações muito antigas Elas não precisam saber, digamos Precisa, um book de compra e venda. Eu tenho que saber a todo momento tudo que está lá para eu poder comprar e vender. Eu não posso desaparecer em ordem de compra e nem em ordem de venda. Todas têm que estar absolutamente lá. Agora você tem stop loss e stop gain, né? Que você põe um preço que se bater naquele preço, ele vende ou compra. Fica lá parado no book. Exato. O caso que compra isso também. Se eu conseguisse quebrar, eu ainda estou naquela ideia do quebrar ali. Talvez não funcione. A sua quebra que você está colocando aí ajudando o performance. Não, mas uma outra ideia de quebrar. Vamos dizer que vai entrar um... Chegou uma mensagem nova ali, que é esse item ali. Wesley quer comprar ações da Full Cycle por 20. Beleza. 20 é um valor que iria cair na primeira instância, na segunda instância ou na terceira instância? Quebrar pelo valor. Isso aí faz sentido. Você vai de zero a um bilhão. Beleza. E quebra em partições diferentes. Mas daí não muda também o... Mas daí você está distribuindo o book. Vai dar rolo. Você vai ter um pedaço do book de um lado, um pedaço do book de outro. Aí teria que conversar quando for alguma coisa muito no limiar os dois books. O anterior e o próximo, tem como se conversar. Essa transação específica seria mais lenta. E aonde que fica guardado esses dados? Quais dados? As ordens de compra, as ordens de venda. Eu acho que o Kafka é bom para isso também, porque ele mantém a ordem. Você não quer usar um time series database? Ou... Tá, mas eu tô... Mas, por exemplo, assim, ó, caiu ali, compra. Como que eu pego que veio uma nova compra, que tá no meu banco, eu pego a nova venda, aí o que acontece? Tá chegando as compras, as vendas... Oi? Eu acho que eu tentaria não pegar de banco, eu acho que eu tentaria manter isso em memória porque se eu tenho isso num array, por exemplo eu tenho um array de 0, a posição 0 a 1 milhão, aí eu cheguei com uma ordem de 20, eu vou na posição 20 do array e vejo o número que tá lá eu cheguei com 1, que é compra e tem um menos um lá. Aí deu match. Sumiu um cara. Parei uma conta mais ou menos assim. Que é mais ou menos como o Kafka trabalha. Ele tem as posições das coisas e aí ele entra com o dado naquela posição. Tá, então vamos lá. O nosso amigo Gustavo e Lucas, o que vocês estão dizendo é para a gente fazer sistema sem banco de dados, é isso? Não, eu colocaria todas as ordens de vendas, poderia ser num Kafka só. E aí eu armazenava as ordens. Você já está recebendo os dados do Kafka. Beleza, aí eu estou puxando uma ordem lá, valor 20. Eu quero saber se tem venda para ela. Eu vou na posição 20 e vejo se tem um valor negativo, por exemplo. Aí eu chego... Não, não... E se não tiver? Não deu match. Não, não deu match, mas fica registrado. Quando tiver um valor, ele vende. Você não... Você registra o seu valor de compra e venda. Se não bateu ninguém, ele vai ficar lá até você cancelar a compra ou venda. Ou no final do dia. Normalmente ele cancela no dia, se eu me lembro. Beleza. Aí quando chegar o segundo, eu vou voltar naquele índice e olhar. E aí, agora no caso, tem alguém? Esse índ você vai buscar esse índice aonde? num banco de dados ou você vai fazer tudo em memória? esse cara, como ele já está persistido eu posso deixar ele todo em memória porque como é numérico mesmo que a gente for de 0 a 1 bilhão a gente está falando de poucos bytes de memória você tem que pensar que eu tenho o nome o ID do investidor eu tenho o ID da ação, quantas ações eu quero comprar, por quantas ações eu quero comprar. Aí pode acontecer que eu quero comprar 20, mas tem alguém vendendo, mas só quer vender 15. Então eu posso comprar essas 15 e ficar mais 5 pendentes para mim, que eu estou esperando alguém entrar com pedido de venda. Comparcial. Tem como comprar parcial. Bom, independente da regra de negócio, o que eu estou querendo trazer aqui para vocês, galera, e grande parte do que eu estou provocando, é o seguinte. Na maioria das vezes, principalmente nas vezes que a gente vai fazer uma entrevista ou a gente vai pensar no sistema, a primeira coisa que vem passar para a nossa cabeça é, vem perguntar, como é que eu escalo esse meu sistema? cabeça, às vezes é plantada a ideia que escalar horizontalmente é a única solução para que você consiga escalar as suas aplicações e escalar verticalmente a coisa antigona que só ia aumentando o hardware da máquina e dando ruim. Bom, o case que eu queria trazer aqui para vocês, depois eu vou compartilhar com vocês o artigo original do estudo, de forma geral, é o seguinte. Na maioria das vezes, eu estou falando na maioria das vezes, porque eu vi vários cases similares com esse mesmo tipo de solução, mas normalmente esses tipos de solução, eles não escalam horizontalmente. O mais perto que pode chegar é um sharing, tipo que nem o Gustavo falou, que faz sentido porque pelo menos você reduz a carga para negociar tipos de ativo. para negociar tipos de ativo. Mas, por incrível que pareça, raramente você vai precisar usar um sharing dependendo da forma de como você vai estruturar e arquitetar a sua aplicação. Olha que coisa muito louca, galera. Várias pessoas fizeram várias contribuições, mas eu acho que quem matou de cara a pau, isso foi o Gustavo e o Lucas, se eu não me engano. Ponto importante. Uma situação, um negócio desse tipo, que precisa ser processado em 1, 2 milissegundos, ou eventualmente em microsegundos, não pode ter banco de dados. Entendeu? Esses tipos de solução, a primeira coisa que a gente tenta pensar é receber os dados, vou guardar no banco, né? E daí eu vou ficar fazendo consulta no meu banco, e daí para escalar vai dar ruim para caramba. Então, normalmente, esses tipos de aplicação, eles trabalham sem banco de dados, rodando exclusivamente em memória, tá? Porém, o que acontece? Existe um padrão que é chamado de disruptor. Eu não sei se vocês já ouviram falar. Esse cara, no final das contas, ele parte do princípio que você tem um componente aqui que vai ficar, no final das cont contas recebendo os dados. Esse cara aqui que recebe os dados, o que ele vai fazer no final das contas? De forma geral. Um, ele vai armazenar, vocês vão entender o porquê que eu estou falando de armazenamento. 2. Ele vai logar e ele vai, como que eu posso chamar? 3. Deserializar. Tá? O que que isso significa, galera? Significa que, conforme os dados vão chegando aqui, não interessa os tipos de rajada que a gente vai recebendo, esse componente aqui, ele vai rodar, tá? De forma concorrente essas três tarefas. Então, ele pode estar guardando num banco de dados, vocês vão entender o porquê do banco de dados aqui. Ele vai guardar todos os logs para ter auditorio Caramba 4 e de se realizar, sei lá, pegar um dado que está em bytes lá do Kafka e transformar em JSON, por exemplo, ou na estrutura de dados que a gente precisa para ler lá no sistema que vai mexer com a lógica aqui para a gente. O grande ponto é que, daqui para frente, O grande ponto é que daqui para frente, esses dados são enviados para o sistema onde tem a lógica de negócio. Business Logic. E aqui eu vou chamar aqui disruptor o que esse cara faz? ele fica armazenando e etc esse cara aqui, ele vai trabalhar como se fosse um anel com diversas posições porém, eu só posso mandar os dados para ser processado aqui quando eu tenho certeza que eles já passaram pelo menos por essa fase da deserialização. Sendo que esses três dados aqui, eles podem funcionar de forma concorrente. Quando esses dados entram aqui, eles são processados diretamente em memória. Ou seja, quando eles estão aqui, eu sei em qual momento esse cara está fazendo o processamento. E quando esse processo acabou, ele manda para um outro cara aqui, que ele vai ficar responsável, por exemplo, por, estou dando um exemplo simples, serializar os dados e mandar esse dado aqui, por exemplo, por... Estou dando um exemplo simples. Serializar os dados e mandar esse dado aqui, por exemplo, para o Kafka de saída. Então, o que a gente está falando aqui de um sistema desse tipo, galera, é um sistema que realmente ele não escala horizontalmente. E, logicamente falando, não tem como você escalar e fazer concorrência de livros de compra e venda. Se você fizer isso de uma forma muito forte e tentar horizontalizar tudo isso, você vai ter um problema muito grande de concorrência. E esse problema de concorrência vai ser tão grande que vai poder talvez deixar o sistema mais lento do que se estivesse apenas rodando. E é aqui que vem o grande ponto. Você vai ter essa parte coisa aqui rodando apenas em uma única thread. Então, Wesley, você está dizendo que poderia ser feito, eu estou, obviamente, galera, simplificando isso, né? Senão daqui a pouco tem alguém que trabalha aí na B3 e vai falar, esse cara não sabe do que está falando. Mas o que eu estou, obviamente, galera, simplificando isso, senão daqui a pouco tem alguém que trabalha aí na B3 e vai falar, esse cara não sabe do que está falando. Mas o que eu estou dizendo é que você poderia, em tese, ter um único sistema com uma única thread processando todas as transações de uma bolsa de valores. O benchmark que foi feito, depois eu mando para vocês o link do Martin Follower, inclusive, os caras, baseado nesse modelo, obviamente, que os caras criaram um componente, foi rodado em cima da JVM, os caras fizeram uma parada em Java, eles conseguiram, eles estavam conseguindo processar 6 milhões de transações por segundo pra vocês terem uma ideia com um hardware utilizando 32 gigas de RAM, ou seja não é uma máquina nem tão tem menos hoje em dia ela é uma máquina muito pior do que eu estou utilizando agora qual o maior segredo de tudo isso? E aí o Gustavo está vendo uma linha interessante aí, que é a forma de você dar um match de tudo isso aqui, o maior ponto de tudo isso é você conseguir trabalhar com estruturas de dados e algoritmo, o cacete A4, para que você tenha a maior performance possível. E é nessa hora que você vai separar um programador que faz um monte de coisa para aqueles programadores que manjam de algoritmo para caramba. Nessa hora você precisa daquele cara, que não sou eu, inclusive, entendeu? Eu manjo fazer um monte de coisa, mas se fosse para fazer um negócio desse, eu conheço 10 pessoas melhor que eu. Entendeu? E o mais interessante é que a gente fica com aquela sensação, poxa, o meu sistema precisa escalar. Aí você vai fazer uma entrevista e alguém mostra alguma coisa pra você e fala, como é que você escala? Daí você fala, ah, não escala. Daí você vai falar, porra, eu não consigo falar que eu escalo uma coisa numa entrevista. Vai ficar feio aqui pra mim. Mas na realidade, entre aspas, a resposta mais lógica que é realmente você não escalar, rodar tudo isso em memória e daí tem o ponto que ninguém fez a pergunta. Eu tô decepcionado com vocês, pessoal. Qual é a pergunta? O que acontece quando cai? Exatamente. O que acontece quando cai? Eu pensei que como eu tinha o Kafka, dava para buscar de onde estava e carregar de novo os books e segue o processamento. Então, dá para saber de onde estava e carregar de novo os books e segue o processamento. Então, dá pra saber de onde estava. De onde que parou. Mas você não tem todos os books daquela vez ainda. Entendeu qual que é o problema? Talvez fazer um graceful shutdown. Não, cara, imagina. Alguém foi lá e puxou a força da máquina. Caiu um raio no data center. Mas não é por isso que tem o armazenamento ali no disruptor? Você, teoricamente, consegue reconstituir o que aconteceu? Então, vamos lá. Está chegando o bom. Quem aqui já ouviu falar em event sourcing? Tá? Event sourcing, basicamente, você consegue pegar todos os eventos gerados com o sistema e você consegue refazer. No final do dia, provavelmente, inclusive, quando esse artigo foi feito, não existiu Kafka, inclusive, provavelmente. Mas partindo do princípio que o Kafka guarda todo aquele stream de dado, se o sistema cai, como que eu consigo continuar de onde eu parei na realidade não é tão simples por quê? porque pra eu reconstituir o estado que o meu sistema tava até aquele momento eu tenho que reprocessar todas as imagens todos os books desde o início da história até chegar aí. Entendeu qual que é o grande problema? Mas aí tira o checo antes, né? Snapshot. Aí, pronto. Pô! Que bom. Depois que a bolsa fechar, o horário... Na verdade, caiu se já fecha a bolsa, né? Não, se não fecha a bolsa. Caiu, não tem você já fecha a bolsa não, você não fecha a bolsa caiu, não tem problema de fechar a bolsa porque ele só não vai conseguir processar o que você vai ter que fazer? pelo menos nessa solução e que é o que, logicamente, a maioria de vocês pensaram na hora que ele está armazenando e catalogando todas as informações de tempos em tempos, o que você faz? você tira um um snapshot da posição até tal tipo, sei lá até 3 horas da tarde caiu meu sistema às 4 o que que eu vou fazer? Vou pegar o snapshot do book completo que tinha até as 3 horas da tarde, carrega na minha memória, reprocesso tudo, aí tem um ponto importante, quando eu for mandar e quem for receber o dado de volta, o cara tem que conseguir trabalhar com idepontência, concordam comigo? Porque senão ele vai reprocessar os dados mais do que uma vez, mas o que vai acontecer na prática é que você vai reprocessar por alguns minutos aquele tempo restante que faltava, vai mandar os dados repetidos, dane-se, e depois continua processando os caras novos que chegaram. Então, basicamente, o que eu queria trazer aqui para vocês é vocês terem um pouco... O que eu queria trazer aqui para vocês é vocês terem um pouco... Aquela história, tem muita coisa que a gente entende conforme parece lógico, mas às vezes a gente esquece que algumas soluções viram padrão, entendeu? E para esses tipos de solução, a gente tem um tipo de padrão que pode trabalhar nesse tipo. Então, basicamente, você trabalha nesse tipo de coisa, uma única thread, porque se você trabalhar multitread aqui, você vai ter problemas ainda de concorrência, mesmo que seja aqui dentro, tá? E... Então, basicamente, você vai ter um programa que vai ser intramemory, né? Que ele vai rolar dentro da mesma thread, você guarda tudo isso, a Kafka acaba já virando o nosso event sourcing aqui, mas você gera snapshots do book de tempos em tempos, pra quê? Pra que você consiga voltar e continuar da onde parou. E aí, você vai tacando memória na máquina e sofrendo pra gerar o snapshot até dava pra fazer uma segunda thread, desde que tu usasse essa mesma thread aqui pra copiar pra uma segunda posição de memória e aí deixa outra thread e se virar daí pra frente é só pra isso, né? eu também faria algo desse tipo também eu geraria uma thread de tempo em tempo só pra coisar. Se eu não me engano, eu li um artigo que chegava à noite, quando o bolso tava fechado, coisa desse tipo, os caras matavam o programa, rebutavam pra limpar a memória, porque sabia que não tinha, sabia de onde tinha parado o snapshot e se tinha qualquer lixo ou qualquer coisa que podia ter problemas com o futuro garbage collector para evitar que o garbage collector fique passando o tempo inteiro os caras reiniciam o programa lá uma vez por dia limpa tudo, continua o snapshot mas é o que os caras estavam fazendo por quê? porque fazer isso cada vez mais com memória limpa, menos você que exige que o garbage collector fique passando, entendeu? Quanto mais tempo for rodando, mais o garbage collector, conforme o tempo vai passando, ele vai ter que rodar lá em cima, entendeu? Então, galera, era basicamente esse case que eu queria trazer aqui para vocês. Depois eu vou passar, deixa eu até pegar aqui, Martin Follow, microservices não, disruptor. É esse, é o Max Architecture? É, eles fizeram esse padrão, eu vou até passar aqui para vocês o software que eles desenvolveram. E se eu não me engano está open source esse padrão. Eu vou colocar aqui no chat para vocês. Dá uma olhada nesse cara aqui. Wesley, você me lembra, você já ouviu falar em Bloom Filter? Que o Chrome usa. Sim, Bloom Filter. Ele vai trabalhando com bits e bytes, ligado, desligado, e você consegue local, você consegue fazer uma busca ali, né? É, ele, tipo, pega, faz uma matriz gigante, por exemplo, o Chrome usa isso pra saber se a URL é válida ou não. Se ela tá na blacklist deles ou não, pra dar aqueles avisos de segurança. Então ele faz uma matriz gigante e quando você joga uma URL, ele passa no algoritmo de hash e chega no endereço de memória. Se tiver um nele, você sabe que aquela URL é inválida. Então, a gente está falando de milhões de URLs e isso é um arquivinho de 5, 7K, entendeu? É bizarro, ele trabalha com conjunto de bytes. Eu acho que o maior problema desse aí é conseguir fazer aquela conta dos matches, etc. É, chegar nesse... Esse é o problema, mas quer ver? Se eu não me engano, quer ver? Eu tinha lido, não sei se onde que foi, que o tamanho do ring deles era de 4 milhões de posições. Aqui, ó. O buffer deles, ó. O ring, né? Onde fica trafegando os dados nesse array que eles ficam rodando, eles têm 20 milhões de slots, né? E pra cada output buffer, eles têm 4 milhões de slots. Ou seja, dá pra ver que eles têm um espaço bem grande de memória mesmo pra ficar rodando e fazendo essas informações. Depois eu queria que vocês lessem tanto esse artigo, mas também dessem aqui só o Martin Fowler falando, mas eu queria que vocês olhassem esse cara aqui, ó. Tá? E depois tentem entender bem o que é o disruptor. Como é que esse funciona? Entendeu? Entenda como é que esse cara funciona eu acho que quanto mais a gente estudar coisas que, mesmo que você não vá usar no dia a dia, vale a pena pra gente ter mais soluções e coisas no nosso repertório às vezes você nunca vai usar isso mas essa ideia acaba quebrando uma crença limitante. Por exemplo, todo sistema tem que escalar horizontalmente. Será que tem mesmo? Pelo jeito não, entendeu? Então, é importante a gente ficar vendo, estudando, olhando para esses tipos de casos, porque realmente tem muita gente fazendo coisas muito loucas que a gente nem era nascido ainda e os caras já faziam isso aí com o pé nas costas entendeu? Então vale bem a pena vocês darem uma olhada eu comecei a cair um pouco nisso só pra vocês saberem, na próxima imersão que a gente vai fazer, a gente vai fazer um home broker e um sistema de trading. E ele não vai escalar? Então, e aí o que aconteceu? Eu comecei a cair nessa história, por quê? Porque eu tinha que começar a fazer isso, o Luiz ia fazer o Next.js, fazer o front-end, clicar, mano, não sei o quê, mas eu tinha que fazer a parte de matching, entendeu? E daí eu comecei a pensar, porra, cara, tá esquisito pra caramba ter que fazer isso rodar num banco de dados, porque o banco de dados vai morrer se eu estiver rodando com um monte de instâncias. Mas será que se fizer só numa instância só, também não tem alguma coisa errada, entendeu? E daí eu comecei a olhar, olhar, pesquisar, e bati aqui. E daí bati em outros montes de lugares, daí você pergunta no GPT baseado nessa situação aqui quais outros casos similares a esse daí ele traz um monte, entendeu? daí você começa a ver que tem uma coisa muito padrão nesses caras que eles trabalham single thread pra fazer o match desses books entendeu? e daí eu fiz a minha versão em Go, fazendo essa parada de pegar parcial, comprar e etc, e conforme ele processa, ele manda, da onde que ele parou, ele continua. Mas eu não vou fazer a parte do snapshot, porque é só pra imersão mesmo, mas foi legal a brincadeira, eu tenho que refatorar o código, já tá pronto, e etc, mas foi legal a brincadeira eu tenho que refatorar o código, já tá pronto e etc, mas ficou legal, tô rodando com três threads, uma thread de produção, uma outra thread de consumo e a thread principal onde fica fazendo esse match tudo jogando pra memória e teve uma pegadinha só, quem aí trabalha com Gol? Ok, tudo bem, ninguém trabalha com Gol tudo bem, o grande ponto, vocês tem que tomar cuidado é que na hora que você está trabalhando com esse tipo de coisa e você vai pegar tudo isso em memória o que vai acontecer? isso aí vai cair em uma função, isso aí vai ficar na stack e daí o que vai acontecer? stack overflow vai bugar, então o que você vai ter que fazer? você vai ter que implementar um container num pacote heap do Go. Aí, quando você pega esses dados, você implementa essa interface, você dá um heap init, aí todos esses dados que eles vão trabalhar, eles vão trabalhar tudo na memória heap. Daí, você pode crescer da forma que você quiser, entendeu? Então, é só um detalhezinho aí pra não ter um stack overflow. Tá bem ligado das diferenças de heap e stack, para não ter esse tipo de problema. Mas é só um detalhe, daí na imersão a galera vai ver. Depois eu mando o código para vocês também. Deixa eu refatorar, só para vocês não ficarem falando que eu sou muito porcão. Ou é só uma dúvida. Com relação ao snapshot, o fato de eu fazer uma nova thread Não é perigoso Porque eu vou estar sempre Um pouco desatualizado Ou posso duplicar alguma coisa Não teria que fazer um lock mesmo Boa pergunta Não sei Eu não parei pra pensar Eu não parei pra pensar com calma Mas eu tenho Aí não tem problema Se tu usar a mesma thread que é a thread que faz as transações Eu não parei para pensar. Eu não parei para pensar com calma. Mas eu tenho esse... Aí não tem problema. Se tu usar a mesma thread, que é a thread que faz as transações, para copiar para uma segunda área de memória, e aí terminou esse serviço, tu continua trabalhando, e dispara agora a segunda thread para ler do segundo local de memória, aí tu tens o snapshot real. Mas aí não seria um lock? Não. Não, não é um lock. Porque, de certa forma, parei de fazer tudo pra copiar tudo da memória pra passar pra um outro endereço de memória. Só que vai ser bem rápido. Parei de executar o programa, né? Cara, na... Bom, ok. É um lock. Eu acho que ele dá uma... Quando, por exemplo, no Red, você escolhe lá o tipo de consistência que você quer ter, né? Pra ele, quando você grava. E aí, se você quer uma consistência muito forte, ele vai tirando os snapshots toda hora. Ele tira os snapshots, é. Aí fica mais lento. Então, eu acho que ele dá um lockzinho. Eu acho... Deve ser alguma espécie de um lock, honestamente, galera, eu não sei. Eu não sei e provavelmente, quem sabe, são esses caras que mexem com o Reds, por exemplo, ou qualquer pessoa que trabalha com esse processo de tirar snapshot. Porque snapshot não é simples de fazer. Mesmo você fazendo um snapshot de um sistema operacional, desde uma VM que você faz, tem um monte de processo rodando que está gerando um arquivo e não está, e o que acontece na hora que ele tira, entendeu? Então, realmente, não é fácil, e provavelmente não seria, se eu tivesse num projeto desse, provavelmente não seria eu que iria fazer um snapshot, ou eu iria precisar de um tempo pra estudar bem aí, mas o que talvez eu faria, honestamente, eu falaria, eu vou iniciar o snapshot em 10 segundos, então eu pegaria o tempo fixo a partir de 10 segundos, pegaria todos os dados que estão passando na thread principal, jogaria pra um canal também, e pra ela ir caindo pra esse novo canal também, e esse outro canal eu vou guardando pra gerar o meu snapshot, eu faria isso, eu ia fazendo, drenando esses dados, mas a partir de uma data limite, entendeu? Eu acho que provavelmente eu faria alguma coisa desse tipo não pensei honestamente a fundo, tudo que eu falar aqui pra vocês vai ser mega especulação mas provavelmente você vai ter que especulação, mas provavelmente você vai ter que, por exemplo, tô pensando falando com vocês, pensando no gol, tá? Se eu fosse no rush, eu ainda fazia diferente ainda. Mas no gol, o que eu faria era sempre, quando o dado passar no canal principal, eu jogar ainda esse dado, ter um processo de fanout, que vai pro processo do snapshot. Entendeu? E depois eu pego a última data daquele dado que eu peguei e falo, o snapshot é dessa última data. Faria alguma coisa desse tipo, provavelmente. Eu tava pensando uma coisa redundante, sempre salvar em dois endereços de memória. É porque daí... Sim, dou pro cadê os dados, mas sempre seria fácil para fazer o snapshot. É que daí você teria que rodar dobrado. Eu acho que na hora que você vai rodar o snapshot, você tem que levantar uma thread e redirecionar os dados da thread nova, mandando também para a thread antiga, um fanout mesmo, e esse fanout fica guardando esses dados, pega o dado, vê qual o dado mais velho que aconteceu e fala, esse snapshot é desse dado mais velho. Eu acho que eu faria alguma coisa nesse tipo. Eu acho que funciona, não sei. Teria que pensar um pouquinho melhor, mas seria alguma coisa desse tipo. Mas, se você fosse fazer uma solução no bem que dá vida, vamos dizer assim, transações bancárias, etc você também seguiria por esse caminho ou você faria já um esplanamento horizontal? Ah não, aí com certeza é o, então, novamente com certeza dá onde? Você falou de um banco, você tá falando de qual parte do banco, entendeu? Então, transações em geral. Transações bancárias, PIX, essas coisas todas aí, tudo horizontal e usando banco de dados. Entendeu? Isso aí não tem tanto... É porque ele usa a consistência eventual. O banco mesmo usa a consistência eventual. Não tem problema. Esse caso aí só tem que ser desse jeito porque você tem que ter dois books e ficando dando match de um pro outro e quando os dois dão match, você tem que remover esses caras, entendeu? Basicamente é por conta disso. Se não tivesse que fazer essas comparações em microsegundos ali, aí daria pra botar em outro banco de dados. Mas de forma geral, em bancos assim, cara, isso aí eu já consigo te responder de cara. Eu tenho 10 milhões de amigos, trabalho em 10 milhões de bancos diferentes. Tudo consistência eventual. O cara faz um PIX, vai olhar o saldo, tá com o saldo antigo, vai ver o extrato, tá com o negócio saído novo, passa 10 segundos, o extrato antigo ficou com o valor novo, entendeu? É tudo consistência eventual. Em banco tudo pode demorar, cara. Porque o tempo é nosso, na verdade, não é seu. Você faz o PIX, a gente vai determinar. É isso aí. Exatamente, entendeu? Agora, na bolsa é crítico, né? A pessoa só vai movimentar aquela ação se ela sabe o valor do ativo. E pra ela saber o valor do ativo, ela tem que saber a última negociação. E sabe o valor do ativo. E pra ela saber o valor do ativo, ela tem que saber a última negociação. E pra saber a última negociação, ela tem que saber em questões de segundos. Então, é foda mesmo. É um domínio muito diferente, de forma geral. Beleza, valeu. Show? Eu tenho uns camaradas na XP, se não me engano, a galera XP fez uma parada de criptomoedas, um tipo fez uma parada de criptomoedas, um tipo de uma parada para vender e comprar. Eu vou tentar falar com os caras e quem sabe eu trago eles para uma imersão pedindo para eles contarem um pouco melhor como é que eles trabalham essas paradas. Essa é bem legal. É porque ainda na criptomoeda ainda tem o blockchain, né? Para ele fazer... Putz, vai mais longe aí. Aí isso aí eu me desço. Aí fazer é mais longe aí sair o negócio mas provavelmente nesse trading que eles fazem eles têm um pouco de valor deles ali né para absorver né eles têm uma camada antes de mandar para o bloco tem blockchain provavelmente é uma segunda é um segundo processo e que manda né porque no caso é pelo que eu ouvi falar eu acho que não era possível sacar as criptas de lá né então até onde eu entendo eles devem ter um nó é ligado na rede da da blockchain lá das criptas ou não sei quantas criptas são mas aí tipo roda só internamente lá a gente não não tem acesso aí essa parte é eu vou dar um exemplo aqui pra vocês, tá? Eu não sei o porquê que eles fazem isso. Eu moro aqui nos Estados Unidos e quando... Eu comprei Bitcoin semana passada. E eu uso a Coinbase. E a Coinbase funciona assim, eu quero comprar tanto, pum, comprei. Ele faz o débito na minha conta bancária, é ACH, eu não sei se alguém mora nos Estados Unidos, como é que funciona, mas ele só deixa você sacar, tirar da Coinbase cinco dias depois que você comprou. É o lucro deles. Porque, se eu não me engano, tanto ação como Bitcoin, quando você tem uma corretora, você compra, eles transacionam dentro da corretora. Então, se tem alguém querendo vender dentro da corretora e alguém querendo vender fora da corretora, eles estão... Nem vai para... Exatamente. Nem vai para fora. Então, eles ganham nessa diferença. Eles têm os spreads dele e vão mais longe ainda. Depois que essa compra é concluída, depois desse tempo, você não pode sacar, constalar o seu negócio como compra e, na minha conta bancária, ainda nem tinha sido debitada. E é mais ou menos como acontece em Bolsa de Valores. Você faz uma ordem de compra, ela dá liquidade, você tem dois dias ainda pra botar o dinheiro pra conseguir concluir aquela operação. Então, ou você está caloteiro, ou você se ferrou lá com os caras, entendeu? Mas é aquela história. Uma coisa é completar a transação, outra coisa é pagar. São processos diferentes. Então, acho que é basicamente isso. Pessoal, espero que vocês tenham gostado desses tipos de casos, depois vocês me dão um feedback, eu acho que é legal sempre a gente poder navegar em domínios diferentes, ver padrões diferentes, como pessoas estão resolvendo problemas de formas diferentes aí, tá? Depois, quem curtiu, coloca aí no chat que curtiu, eu vou sempre estar procurando cases um pouco diferentes, com arquiteturas e pontos diferentes, porque no final das contas é o que é é o que vai aumentando o nosso repertório, né e eu acho que conforme a gente vai conversando com outras pessoas, a gente vai conhecendo outros pontos de vista, outras soluções e eu acho que isso aí é bem bacana mesmo, a gente vai conhecendo outros pontos de vista, outras soluções, e eu acho que isso aí é bem bacana mesmo a gente conseguir trabalhar. Pessoal, seguinte, vamos agora para a nossa segunda etapa aqui do nosso encontro, que é o Hotseat, tá? Como é que funciona o Hotseat, galera? Hotseat funciona da seguinte forma. como é que funciona o hotseat galera hotseat funciona da seguinte forma vamos imaginar que eu hoje estou com um problema no meu trabalho problema de liderança um problema que eu acabei de virar tech lead ou um problema de um algoritmo ou um problema de uma arquitetura que eu não estou conseguindo escalar, não interessa então o que vai acontecer quando o hotseat começar a gente vai vocês vão ser redirecionados interessa. Então o que vai acontecer? Quando o hot seat começar, a gente vai... Vocês vão ser redirecionados pra uma sala auxiliar aí no Zoom. Vocês não vão precisar fazer nada. E nessa sala vai ter cinco pessoas. Você e mais quatro. Você vai poder ter aproximadamente aí uns dois, três minutos pra falar o seu problema. Tá? E vocês vão ter aí mais um torno de uns sete minutos dessas quatro pessoas que estão junto com você dando insights e dicas de como você pode resolver esse tipo de problema. Deu esses dez minutos, vai voltar para a sala principal, vai resetar o tempo e aí quem tá no hot seat é outra pessoa. Até rodar as 5 pessoas. Fez sentido isso pra vocês, galera? Então, como que vai funcionar a ordem? Como que vai funcionar o esquema do hot seat? Quem tem o cabelo menor, começa. Vai ser assim hoje. O menos cabeludo começa, vai ser a pessoa que vai tirar a dúvida e as outras quatro pessoas vão ser as pessoas que vão ajudar essa pessoa. Daí, quando voltar para a sala, voltar na sala, a segunda pessoa que tem o cabelo menor e assim vai. Todo mundo é programador, então hoje é o dia dos carecas beleza? ponto importante como o tempo é contado eu queria nesse momento que vocês tirassem um minutinho para pegar uma caneta de papel ou bloco de notas, da forma como vocês quiserem e pensem em uma dúvida que vocês gostariam de tirar, que poderia te ajudar para alguma coisa de forma profissional. Você está querendo passar em uma entrevista? Você está querendo mudar de cargo? Você está querendo aumento? Você está querendo aprender um algoritmo melhor? Você está com uma dúvida estrutural? Você está com uma dúvida de cloud. Cara, a dúvida que você tiver, vamos ver se os nossos amigos conseguem te ajudar. A ideia aqui é que vocês consigam usar o conhecimento do grupo mesmo para vocês se ajudarem e ao mesmo tempo que vocês também possam conhecer outras pessoas, apesar no final das contas, a gente está fazendo o MBA. Grande parte do MBA também vem também do networking, né você conhecer pessoas novas, pegar o contato pegar o zap da galera só tem uma regra, galera só tem uma coisa que é um crime se alguém fizer o crime é sair falando pergunta da prova tá? não pode falar pergunta da prova aí não vale falar a pergunta da prova. Aí não vale. Eu tinha tido essa ideia. Mas agora que você deu essa ideia... Ninguém tinha pensado nisso, né? Agora, pronto. Então, vocês botaram as suas perguntas aí? Anotem as suas perguntas. Quando vocês falarem que está ok, me falem. Eu vou pedir aí pro Léo já organizar aí tá tudo tá tudo no gatilho aí, ô Léo? tudo certo não vai expulsar todo mundo aí não, né? não, pelo amor de Deus vamos lá então então maravilha, galera bom, quem eu não ver mais hoje à noite, tá? vamos lá então então maravilha galera bom quem eu não ver mais hoje a noite tá, é porque acabando o Hotseat depois fechado o Zoom galera, eu queria dar mega boa noite aí pra vocês espero que vocês tenham curtido o papo de hoje e espero realmente que o Hotseat ajude vocês que vocês conheçam pessoas super legais aí e que eventualmente vocês possam fazer futuras parcerias ou qualquer coisa desse tipo. Maravilha?