Galera, a brincadeira nossa aqui hoje vai ser focada em System Design, tá? Então, a nossa ideia aqui é que vocês consigam fazer uma lousa branca de um System Design pra um sistema de armazenamento de arquivos, tipo um Dropbox, um Google Drive, essas aplicações onde você consegue fazer o upload de arquivos, gerenciar a versão dos arquivos e você pode ter diversos clients ali no mobile, se instala um desktop pra ele ficar sincronizando, tá? Então a ideia é a gente conseguir montar esse tipo de system design, tá? Então como é que vai ser? A gente tem três etapas aqui principais, tá? Uma etapa aqui que eu quero trazer aqui pra vocês é a lousa branca tá, então basicamente é fazer o system design, então nesse caso a gente tem alguns requisitos aqui funcionais pra vocês saberem na hora de desenhar então a gente tem sincronização de arquivos entre os dispositivos. Vocês não precisam anotar, galera, porque vocês vão ter acesso a esse doc aqui só para vocês saberem. Beleza? Então, vamos lá. Sincronização de arquivos entre dispositivos. O client tem que receber notificação em tempo real quando os arquivos forem atualizados. O servidor, obviamente, tem que poder mandar notificações, o servidor tem que ter um endpoint claro para disponibilizar os arquivos e os pedaços dos arquivos, para que os clients consigam acessar. Os arquivos devem ser versionados, ou seja, não é o versionamento do projeto ou dos arquivos que a gente sobe. Então, se a gente sobe um documento e cada vez que esse documento altera, eu vou ter as versões desse documento que a pessoa pode ver as versões mais antigas. Obviamente, os clientes podem criar, modificar, excluir os arquivos ali para a gente. Alguns pontos aqui que eu coloquei como requisitos não funcionais, mas na realidade é mais para vocês se ligarem e sempre pensarem. Isso aqui acaba meio que sendo uma dica na hora que vocês forem criar esse System Design, que é resiliência. Então, o sistema deve continuar funcionando em caso de falhas parciais. E eu quero que vocês pensem muito em relação a baixa latência. Então, como que a gente consegue fazer para, um, a gente ter alta disponibilidade, a gente conseguir baixar rapidamente esses arquivos, a gente conseguir mandar essas notificações em tempo real também. Um ponto importante também é a parte de concorrência, porque a gente tem que garantir consistência e evitar conflito em operação simultânea. Por exemplo, eu estou subindo vários arquivos em dois clients diferentes. Como é que isso vai ficar? Legal? Uma dica que eu dou aqui para vocês é vocês utilizarem o Scaledraw. Eu não sei se vocês conhecem, mas também vocês fiquem na liberdade de usar a ferramenta que vocês usam. Eu utilizo o Scaledraw, então eu estou colocando aqui como sugestão. Beleza? Aí, o seguinte. Uma coisa importante aí, e que é muito em relação como provocação, é eu queria que vocês criassem uma estrutura básica de como que ficam os bancos de dados em relação a isso. Então, por exemplo, tudo que a gente colocar aqui é uma visão de alto nível. Então, quando eu falo de um endpoint de arquivos, é óbvio que um sistema desse teria um trilhão de endpoints. Mas, obviamente, que endpoints principais, por exemplo, é de fazer download dos arquivos, ou fazer um upload de arquivo. Mesma coisa com banco de dados, ia ter um trilhão de tabelas nesse banco, mas o que são pontos importantes num banco de dados nesse caso? Provavelmente gerenciamento de arquivos para os usuários, a forma como os arquivos são organizados, e também os tipos de bancos de dados. Normalmente, esses tipos de sistemas, eles utilizam diferentes tipos de bancos de dados para diferentes casos. Obviamente, se vocês quiserem colocar apenas um tipo, se vocês acham que vocês resolvem todo esse problema com MongoDB, ou se vocês resolvem todos esses problemas com PostgreSQL, com MySQL, com banco de dados relacional, NoSQL, etc., vocês também podem colocar sugestão, mas lembre-se que vocês também estão abertos aí para vocês poderem utilizar outros tipos de banco de dados e diversos tipos de banco de dados simultaneamente para casos específicos, tá? Uma coisa mais chata, né, e a gente sabe que toma mais tempo, a gente tem no módulo do System Design, no próprio curso, por exemplo, do MBA, a gente mostra como criar planos de capacidade, coisas desse tipo. Eu estou colocando aqui como opcional, mas seria bem interessante se vocês tiverem tempo de conseguir fazer um mínimo de planos de capacidade o ponto importante aqui que eu digo é vocês tem que sacar que um dos pontos provavelmente bem importantes é vocês tentarem entender se esse sistema é um sistema de de leitura intensiva ou um sistema de escrita intensiva e provavelmente a storage e tráfego de dados, eu acho que são os principais pontos em relação a plano de capacidade mas assim, obviamente galera, plano de capacidade principalmente em system design, normalmente ele vem antes até mesmo, principalmente antes do system design, inclusive dependendo da situação, ele vem antes inclusive de banco de dados do System Design. Inclusive, dependendo da situação, ele vem antes, inclusive, de banco de dados ou design da API que vocês poderiam colocar. Então, não precisa necessariamente colocar o design da API ou os principais endpoints, mas provavelmente, na hora que vocês forem desenhar, a gente vai ter vários serviços ou vocês querem fazer um sistema monolítico, mas provavelmente a ideia é, a gente vai ter vários serviços, ou vocês querem fazer um sistema monolítico, mas provavelmente a ideia é que a gente consiga trabalhar aí com arquitetura distribuída. E aí, nesses casos, provavelmente existem serviços específicos que vão ter upload, download de arquivos, modificações. Então, eu não quero chegar em detalhes específicos de endpoint. É uma visão de alto nível, modificações. Então, eu não quero chegar em detalhes específicos de endpoint. É uma visão de alto nível. Fechou? Então, essa que é a ideia. Então, a ideia principal agora é o quê? Uma vez que vocês têm uma visão meio que geral, eu queria saber se vocês têm algumas perguntas. E agora é o momento de perguntar. Normalmente quando a gente está fazendo processos de System Design, essas partes de fazer perguntas, vamos dizer assim inteligentes, que vão ajudar vocês montarem, são importantes. Então, assim, fiquem na liberdade de fazer as perguntas. Vocês têm mais alguns minutinhos e daí a gente faz essa quebra aí do breakout room, ok? Beleza. O Evandro ligou a mãozinha. Galera, por favor, quem puder, liga a câmera principalmente nas breakout rooms porque vocês vão estar em grupo, né? Então, ficar com todo mundo com câmera fechada às vezes fica um negócio meio, talvez meio impessoal. Fechou? Então, vamos lá. Mãozinhas levantadas. Evandro aí tá com o primeiro. Evandro, manda ver, cara. Oi, pessoal. Tô aqui na veraniana daqui. Aí eu tô bem à vontade. A pergunta é qual é o nível da infraestrutura que a gente vai ter na infra? Porque se a gente for usar, por exemplo, o CERF, que é tipo um serviço da W3, Open Source, você vai poder ter esse nível de infraestrutura? É alto nível porque ele já fornece receber arquivo, já fornece ter inversionamento de arquivo. A gente pode usar, tipo, uma infraestrutura dessa ou tem que ser uma coisa mais baixo nível? Não precisa ser totalmente baixo nível nesse tipo, mas, assim, vocês podem optar para utilizar qualquer tipo de infraestrutura que vocês achem necessárias. Por exemplo, ah, talvez faça sentido eu pegar os arquivos e guardar no S3 da AWS, né? Ou eu vou ter um sistema pra evitar lock-in e eu vou ter uma infraestrutura própria pra fazer esse gerenciamento de arquivos. Isso pra mim tanto faz assim. É abertura total pra vocês fazerem do jeito que vocês quiserem. A minha única dica é não ficar necessariamente tão preso a detalhes de infraestrutura, por exemplo, qual serviço vai usar para fazer aquele tipo de coisa? Ah, isso aqui vai usar o RabbitMQ, não precisa falar que é o RabbitMQ ou que é o Kafka, fala que é um sistema de mensageria, entendeu? Não necessariamente precisa dizer que é um S3, mas pode colocar um serviço de armazenamento de dados. Então, não precisa deixar ali tão explícito qual é o serviço, de qual nuvem e etc. Obviamente, se tem alguma coisa que pra vocês vai facilitar muito aí nesse caso, aí vocês podem citar, tá? Mas não precisa ficar preso com serviço de nuvem ou ferramenta em si. Fechou? Aí a gente tem o Felipe aí, que levantou a mãozinha também. Boa noite. Essa questão da notificação em tempo real, é notificar que o arquivo, que teve alteração no arquivo, ou já recebeu ele? Estou perguntando mais assim, pensando no Google Docs, que tem aquela interação em tempo real com o mesmo documento aberto. O foco é sincronizar os arquivos, mas a sincronização do arquivo não ter essa pegada tão forte em real time e só a notificação. Basicamente, a ideia é, imagina que eu subi um arquivo, tá? Assim que o arquivo subiu, eu quero ser notificado. Ou fiz a sincronização de vários arquivos. Opa, né? A sincronização aqui desses arquivos acabaram. Basicamente é isso. E o versionamento, a gente vai sempre manter o versionamento? Sempre manter o versionamento. Então, eu subi um arquivo chamado a.txt. Versão 1. Subi o a.txt de novo. Tenho a versão 1 e tenho a versão 2. Ok. Pedro. Opa, primeiramente uma ótima noite para todo mundo que está participando aqui da dinâmica pois bem, eu tenho algumas dúvidas e a primeira em relação quando você fala sobre modificar, implica em editar o arquivo em tempo real cara, é upload imaginando uma colaboração eu estava pensando num cenário onde está todo mundo editando o mesmo Excel ou PowerPoint em tempo real. Cara, é upload. Ah, não, tudo bem. Eu tava pensando num cenário onde tá todo mundo editando o mesmo Excel ou PowerPoint, que já implicaria pensar em alguma estrutura de CRDT ou algo nessa linha. Não, não, não. Basicamente é um drive de arquivos, tá? Então não tem nenhuma ferramenta tipo do Google, tipo um Google Docs que altera, nada disso. É armazenamento de arquivos mesmo. Maravilha. E outro ponto que você até acabou comentando, mas que agora eu reforço, em relação à estrutura do plano de capacidade, de quanto que a gente vai estimar de uso, você tem algum número esperado de usuários, pra gente partir disso como exemplo, pra poder gerar o número esperado de tanto de tráfego de banda, consumo, que a aplicação vai ter? A gente pode estimar esse número? Vocês podem colocar um número estimado, mas eu colocaria aí que, inicialmente, a gente teria em torno de 10 mil pessoas cadastradas no sistema colocaria aí que, inicialmente, a gente teria em torno de 10 mil pessoas cadastradas no sistema e que, em média, essas pessoas, elas modificam ou fazem upload de novos arquivos a cada pessoa em torno de 10 arquivos por dia. Maravilha. Beleza. Então, é isso. Só a última coisa sobre a questão de usuários Serem notificados A ideia vai ser basicamente Fazer um push Da forma Como você achar melhor Você escolhe o protocolo Você escolhe a forma Entendeu? Da forma que vocês acharem melhor. Maravilha, muito obrigado. Pode ir aí, Lucas. Show de bola. E aí, doutor Lucas, firme e forte? Opa, boa noite, pessoal. Estão conseguindo me ouvir certinho? Perfeito. A minha complementa do Pedro, que era em relação ao plano de capacidade também, você falou de 10 pessoas, a cada pessoa fazendo 10 modificações ali, então eu entendo isso como rights. E de reads, de leitura, qual que seria a média? Show de bola. Bom, o que vocês têm que pensar aí, então é bom vocês colocarem isso porque já é interessante aqui eu já começo das dicas em relação a se o sistema é um sistema de leitura intensiva ou se é um sistema de escrita intensiva aí em relação a leitura de arquivos e etc, aí acredito que a gente pode colocar que por dia, cada pessoa vai interagir com pelo menos 25 arquivos. Ou seja, provavelmente ela vai fazer download desses arquivos. Ela vai abrir esses arquivos de alguma forma. E um outro ponto importante pra gente não complicar, porque daí o plano de capacidade fica mais complexo, é que tem pico de usuários. Por exemplo, a primeira vez que o cara entra, ele pode sincronizar, sei lá, 500 arquivos. Então daí isso pode mudar bastante a forma de criar o plano de capacidade. Mas não precisa pensar nessa parte. Então, vamos ignorar qualquer tipo de setup e pico de uso, principalmente quando tem a carga inicial. Então, vamos partir do princípio que a gente ignora essa parte. Tá, beleza. Show? a gente ignora essa parte. Beleza. Show. Aí a gente tem o de Anderson. Opa, boa noite, pessoal. Acho que a primeira pergunta minha aqui já foi sanada. A segunda é em relação à necessidade de autenticação, de cuidar de autenticação e sincronização de arquivo dado determinados cenários, né? Sei lá, às vezes eu queira compartilhar um arquivo, então determinada pessoa pode ter acesso, dado que eu permiti esse acesso. Cara, não, tá? É um sistema multi-tenancy, obviamente, porque eu tenho diversos usuários, mas se vocês olharem aí nos requisitos, não tem nada de compartilhamento de arquivos com terceiros, tá? E, pessoal, eu vou levantar agora a mãozinha até o Luiz, tá? Pra gente, senão a gente não consegue começar. Então, o Luiz é o último a responder, beleza? Aí, então, a gente tem o David, o Marco, o Levi, o Rodrigo e o Luiz. Bora aí, David. Valeu, boa noite a todos. Vamos lá, essa questão dos arquivos, dependendo do cenário, ela pode ser mais tranquila ou um pouco mais complexa. No sentido de volumetria, esses arquivos vão ser de quais tamanhos? Ou não tem um limite de tamanho? Show de bola. Média de cada arquivo é de um mega. Ah, legal. Show de bola. Valeu. Marco. Valeu Marco Boa noite pessoal Wesley meu irmão faz sentido nesse momento eu perguntar o quão rápido por exemplo você cita sobre baixa latência tempo de resposta rápido mas tem algum número para a gente o quão rápido, por exemplo, você cita sobre baixa latência, tempo de resposta rápido, mas tem algum número para a gente trabalhar? Não, eu não tenho número. Quando eu digo baixa latência, principalmente, é que as notificações, elas têm que ser realmente provavelmente com protocolo, alguma coisa que seja muito rápido, e a forma de que como o usuário vai baixar o arquivo também tem que ser o mais rápido possível aí tem várias abordagens pra você conseguir distribuir esses arquivos pra fazer esses downloads, tá? Certo Tá, e se vocês forem falar em, bom manda ver, é isso aí não quero complicar porque daí na hora da discussão eu vou falar sobre isso também, eu quero ver como é que vocês vão trazer a solução não quero influenciar vocês certo pro system design faz sentido também eu me preocupar como que os usuários vão vão fazer o login? não perfeito beleza show de bola, Levi não perfeito beleza show de bola, Levi cara, se puder ligar a câmera também fica legal eu tô numa cafeteria aqui, não sei nem se vai dar pra me ouvir na real, a gente tá ouvindo sim de boas, mas eu vou ligar já já sim é bom, eu queria só perguntar ali, você falou da questão do download, sobre a sincronização vai contar como interação daqueles 25 downloads ou a sincronização, a estimativa é como uma interação separada? A sincronização depende da solução que vocês querem colocar. Entendeu? Por exemplo, se você quer sincronizar o arquivo apenas para aparecer a lista de arquivos que eu tenho e somente quando eu abrir o arquivo ele faz um download, é uma coisa. Você também pode escolher, por exemplo, quando você sincronizar, você vai fazer os downloads. Então, isso aí fica a seu critério de como você quer interpretar isso. Perfeito, perfeito. Valeu. Show. Rodrigo? Boa noite, pessoal. Boa noite, Wesley. Cara, eu não sei se eu perdi ali, mas eu não vi se tem alguma limitação de tamanho que cada pessoa sentiu. Tipo, tamanho máximo de coisas que podem ser feitos o upload pra lá. Tip tipo, tamanho máximo de coisas que podem ser feito upload pra lá, tipo, tamanho máximo de armazenamento. Show de bola. Tamanho máximo de armazenamento, 1 giga. Tá, então passou de 1 giga, corta o acesso do cara subir, então. Corta o acesso. Beleza. E, finalmente, Luiz. Opa, boa noite Wesley, boa noite pessoal. Na realidade, eu tenho duas perguntas. Primeira questão, pensando em um lifecycle desses arquivos, eventualmente esses arquivos vão entrar em estado de acesso infrequente e, posteriormente, até mesmo serem expurgados, até a questão do versionamento, ou não, eles nunca vão entrar nessa situação e sempre tem que estar disponíveis ao toque de um clique, digamos assim. Então, eles nunca vão ser deletados, nunca, de forma alguma. Agora, fica a seu critério e na sua solução se você quiser colocar de alguma forma que os arquivos muito mais antigos em relação a versionamento eventualmente ele pode entrar não como uma parte de arquivo quente ou qualquer coisa desse tipo obviamente a última versão ela jamais pode estar num Glacier da vida ou qualquer coisa desse tipo. Tá. E o segundo ponto é com relação a uma consistência eventual. Por quê? Pensando que eu vou fazer uma distribuição entre várias AZs, usando, por exemplo, um CDN ali, no caso, sei lá, um CloudFront ali para fazer essa distribuição. Pensando nesse cenário, pode acontecer de um arquivo ser utilizado em um ponto, em um local, e se a mesma pessoa tentar, por exemplo, usar esse arquivo imediatamente depois, eu posso ter um cenário que o arquivo ainda não foi atualizado nessa Z ou nesse CDN. Nesse cenário, tudo bem? Ou não? Teria que ter uma consistência forte entre todas as Zs? Não sei. Me traz a solução. Tá bom. Fechou? Galera, seguinte agora, tá? Deixa eu parar de compartilhar minha tela. Eu vou colocar agora no chat o link. Espera só um pouquinho. Deixa eu só colocar. Veja se vocês... Nossa, eu quase mandei uma mensagem aqui só para o Alex. Espera aí. Everyone. Cara, eu não quero mandar direct message. Cara do céu. Pera aí. Galera, eu mandei uma mensagem aí no chat tá, veja se vocês conseguem abrir esse arquivo Sim Sim Beleza, então esse é o link do arquivo, tá eu vou esperar 30 segundos pra vocês copiarem e poderem abrir e daí o que eu vou fazer, eu vou preparar aqui tá, as salas então a ideia é que vocês fiquem separados em torno aí de 5 salas, de 5 salas não em grupos aí de 5 pessoas aproximadamente, pode ter uma sala que tem algum grupo ou não, e de tempo em tempo aí eu vou dar uma de orelhudo e entrar em algumas aí para ver como é que vocês estão indo também. Fechou? Então eu vou colocar aqui... Eu vou colocar aqui... Para ele criar as salas. E na hora que eu der essa criação eu vou colocar agora aí pra vocês pra vocês poderem entrar aí fechou? tem gente chegando agora ou entrando ou saindo aqui do zoom então eu tô dando um recreate aqui pra vocês mas na média aqui é em torno de 5 pessoas, tem algumas salas com 4 pessoas aí também fechou? Então galera uma outra coisa eu vou colocar aqui, tá pra 40 minutos pra vocês fazerem isso, tá? E eu vou colocar um countdown de 2 minutos que o Zoom vai avisar vocês que a sessão ela tá acabando somente pra vocês não darem nem tempo de falar tchau pros seus colegas aí, fechou? Então tô setando isso aqui e boa sorte aí galera bora nessa Bom galera, agora que a gente voltou das breakout rooms a gente vai pegar dois grupos aqui tá, nesse e a gente discute um pouco em cima da solução deles, não quero ficar muito tempo em cima disso então em torno de 10 a 15 minutos mais ou menos aí e depois eu vou trazer a solução do Fabian Riesenkamp, que é o nosso professor do MBA de System Design esse desafio basicamente é dele então aí a gente discute também em cima, mas vai ser esse desafio basicamente é dele então aí a gente discute também em cima mas vai ser legal porque a gente consegue ver algumas soluções antes Gustavo, você pode compartilhar aí sua tela, eu tenho que deixar você compartilhar a tela como que eu dou? eu acho que já tem já tem? ah, show de bola tá, show de bola só Tá. Show de bola. Só vou puxar os requisitos aqui para eu comentando. Vocês veem a minha tela? Aham, perfeito. Então, assim, a gente pensou numa solução enxuta pensando na AWS, tá? A gente foi um pouco no detalhe, eu acho que isso é importante para explicar alguns pontos ali dos requisitos. Então, só para explicar aqui, basicamente, haveria aqui o cliente e eu escondi todo um front-end ou algum tipo de interação que ele vai ter aqui com o CloudFront, com as press-sign-wire-outs. CloudFront com as press-sign URLs. Então, a ideia é que, através dessas URLs pré-assinadas, ele pudesse comunicar primeiramente com o CloudFront, onde teria um cache de arquivos, um TTL definido, isso para que as operações de GET fossem mais rápidas, não precisasse bater aqui no S3. Com essas press signs URL, eles também poderiam fazer diferentes operações, delete, punch, get. A ideia é que houvesse um bucket só, para que primeiro houvesse uma sincronização dos arquivos entre os dispositivos. Entretanto, houvesse uma organização de pastas por pessoa. Uma dúvida que a gente tinha é que não estava claro para a gente se um cliente poderia acessar os arquivos de outros clientes. Então, a ideia, primariamente, foi dividir os arquivos em pastas e se eu subir um arquivo, eu só posso editar ou puxar essas informações do que eu subir. Então, falando aqui dos requisitos, o cliente deve receber notificações em tempo real quando os arquivos forem atualizados. Então, para quem conhece, existe aqui o S3 Event Notification, que a gente pode configurar toda vez que houver PUDs aqui, ele comunica com a STS e ele faz um PUD ali no celular do cliente, tá bom? O servidor deve ser capaz de... O servidor deve ter um endpoint para disponibilizar os arquivos em chunks, então foi o que a gente pensou aqui nas Precise URLs. Os arquivos devem ser versionados, tá? A AWS 3 ali também tem uma opção de versionamento, tá? Que é bem interessante, inclusive. Depois, os clientes devem poder criar, modificar e excluir os arquivos, então através das Press Science URLs eles conseguem editar e fazer todas essas operações, mas somente de arquivos, então através das press signs, eles conseguem editar e fazer todas essas operações, mas somente de arquivos deles, pensando nessa estrutura de passos aqui. Bom, pensando em resiliência, que é um requisito não funcional, que o sistema deve continuar funcionando em casos de falhas parciais, o serviço da AWS tem, sei lá, acho que nove zeros de disponibilidade, eu acho que esse não seria um problema para a gente. Baixa latência, a gente também pensou num componente que existe na AWS de Transfer Acceleration, que aumenta de 50% a 500%, a taxa de transferência para uploads, ainda mais para quem está longe, tá? Quem está longe ali da region. Depois, pontos de atenção que tem a concorrência, que garantia a consistência e evitar conflitos em operações simultâneas de modificação de arquivos. A gente entendia que o versionamento tem essa capacidade, porque primeiro, somente uma pessoa vai conseguir editar o arquivo dela, mas vamos supor que ela esteja em dois devices diferentes, fazendo a mesma operação ao mesmo tempo, que já é estranho, tá? Difícil. Ela não teria um lock, no nosso entendimento, como há em bancos relacionais, por exemplo, e o S3 faria um versionamento daquele arquivo. Então, assim a gente resolve a questão da concorrência. Sobre os outros pontos, como são os serverless, por exemplo, quantidade de servidores necessários para suportar os picos e manter a latência baixa. Puts, é um serverless, a gente não provisionalizou os servidores aqui. E aí os outros pontos aqui, eu acho que foi o Wesley que já passou, né? O volume esperado de usar esses arquivos, espaço de armazenamento médio necessário para o usuário. Aqui não tem um limite de armazenamento, tá bom? Depois de que são simultâneas previstas, eu acho que o Wesley passou essa informação também. Mas, enfim, basicamente é essa solução, pensando ali, focando no caso do S3, e uma discussão nossa foi, putz, a gente está usando o S3 aqui como uma bala de prata, e a gente sabe que toda bala de prata no mundo de TI é complicada, né? No mínimo, a gente fica com a pulga atrás da orelha. Mas é complicado, né? No mínimo, a gente fica com a pulga atrás da orelha. Mas é isso, tá? Show! Bom, galera, primeiramente... Cara, você pode deixar compartilhado pra gente discutir em cima disso? Bom, galera, primeiramente eu... eu acho que é muito bacana que vocês conversaram foram chegando e conseguiram chegar aí numa solução tá, eu acho bem bacana e entendi bem a lógica do que vocês colocaram e tudo mais posso colocar vocês um pouco na fogueira? fica a vontade cara, o seguinte o que vocês fizeram é muito bacana mas vocês tem um problema bem grande aí. Sabe qual é? Qual? Vocês simplesmente conectaram pontos de serviço da AWS, mas vocês não falaram nada da aplicação de vocês. Por exemplo, você vai ter um serviço que vai fazer o upload de arquivos. Como que esses arquivos vão subir para esse serviço? Você vai ter um load balancer para aguentar a carga desse serviço? Como é que vai ser a parte de armazenamento de banco de dados? Por exemplo, você não vai jogar os arquivos soltos na S3. Concorrência, por exemplo, se dois devices começarem a subir os arquivos, provavelmente você não vai subir direto ele para S3. Você vai cair num serviço seu. Esse serviço vai ter que garantir a consistência pra um fazer o upload depois do outro ou alguma coisa desse tipo, tá? Eu acho que os grandes pontos aqui é que vocês estão mostrando muito a comunicação entre serviços da AWS e menos a parte de da arquitetura do sistema em si. Não sei se faz sentido o que eu falei aí para vocês. Faz sentido o que eu estou dizendo? Sim, você espera que existe uma aplicação aqui por trás que vai fazer o gerenciamento dessa... E é o principal ponto do System Design. O System Design, eu não estou interessado em qual serviço você vai utilizar, se vai ser S3 se vai ser um bloco de storage gerenciado por vocês, se vai ser o CloudFront, se for o Akamai pra qualquer tipo de CDN ou qualquer coisa desse tipo a dica que eu dou pra todo mundo quando for fazer System Design é sempre pense no final das contas no seu sistema, nos componentes do seu sistema, porque o seu sistema, ele é a porta de entrada pra todas as requisições tá, então por exemplo vai ter um servidor web, por exemplo, essa notificação vai notificar o cliente. Como ela vai notificar? Entendeu? Se for pelo browser que o cara está aberto, se for pelo celular, você vai, sei lá, usar um WebSockets, ServerSense Events, alguns outros formatos ou sistemas de eventos, entendeu? Porque o SNS, ele só manda uma notificação para um serviço. Mas qual é o serviço que vai receber essa notificação para notificar o client especificamente, entendeu? Então, o que eu gostei bastante aqui de vocês foi que vocês conseguiram pensar em alta disponibilidade colocando o CloudFront na frente. E isso aí consegue diminuir pra caramba a latência em relação aos arquivos mas tem uma coisa interessante aí e que foi uma pergunta que alguém fez na hora que a gente estava batendo papo, é o seguinte como é que fica a invalidação desse cache? por exemplo, eu acabei de fazer o upload de arquivo, daí eu estou numa outra localidade e eu tenho que fazer o download, eu tenho a chance de pegar esse arquivo antigo? Como que você vê esse tipo de problema aí, Gustavo? E galera, quem tá no grupo do Gustavo, tá? Eu não quero botar só o Gustavo na fogueira não, galera. Quem é do grupo do Gustavo aí, eu quero que vocês abram a câmera e também dê opinião aí de vocês, tá? E Gustavo, faz sentido o que eu tô falando? Por favor Faz total sentido, tá Eu confesso que quando a gente Montou, eu não pensei Numa aplicação que Essas personal URLs seriam basicamente Uma URL pra cada Pessoa, pra que ela pudesse Subir o arquivo diretamente, tá Não pensei no front-end E tal, no servidor, mas, de fato, eu acho que é importante. É que eu estava mais pensando aqui na solução de banco de dados, de como lidar com os arquivos, a questão de resiliência, mas, de fato, o que você falou é bem importante e deveria ser levado em consideração. Referente ao TTL aqui, esse é um ponto importante também, porque se a gente definir um TTL muito grande, a pessoa não vai conseguir acessar o arquivo que ela acabou de subir. É que, na verdade, o upload vai atualizar o cache. Os gets que vão ser um pouco mais complicados. Então, mas aí que é o grande ponto vamos pensar na prática experiência do usuário, acabei de fazer um upload do arquivo pelo meu celular, aí eu vou no meu desktop e faço o download do arquivo aí eu pego o arquivo antigo tem um TTL de 5 minutos que seja, como é que tem uma estratégia que a minutos que seja, como é que tem uma estratégia que a gente usa aí, que é o most recently used, que é a mesma estratégia que a gente usa pra subir videoaula, por exemplo, pra cara não assistir antiga, quando você subir uma atualização, por exemplo que é a estratégia de invalidação de cache, que é a MRU. Show de bola. Por isso que nesses tipos de coisa é interessante. Por quê? Olha só, porque o que acontece é o seguinte, independente se vai armazenar em S3, a gente sabe que o S3 mantém inversionamento e tudo mais, tem um ponto aí que é importante que é o seguinte a gente sempre tem que pensar por exemplo como storage como que eu vou armazenar esses arquivos e como que eu consigo otimizar ao máximo o armazenamento desses arquivos tá, então vamos imaginar que eu vou guardar os arquivos num servidor, uma pasta. Cara, será que eventualmente não é melhor eu separar esses arquivos com layers ou alguma coisa desse tipo, com vários chunks? Guardo esses arquivos, quando tiver uma atualização, eu verifico se eu tenho chunks que são iguais. Se esses chunks forem iguais, o que eu posso fazer? posso mandar só os chunks que são diferentes, ou seja, já economizo um bom espaço também em disco e provavelmente eu tenho que ter tabela de banco de dados, onde eu tenho os metadados dos arquivos onde eu tenho todos os versionamentos e os snapshots com todos os chunks relacionados ali quando eu, onde eu tenho todos os versionamentos e os snapshots com todos os chunks relacionados ali. Quando eu clico, grudo esses caras e faço o download. Então, talvez possa ser uma estratégia que ajude principalmente a economizar dinheiro pra caramba. Quando eu falei do limite máximo de upload de arquivos, é exatamente por isso, pra gente colocar pelo menos uma limitação pela quantidade de chunks e dados que a gente vai subir. É muito tentador subir o arquivo completo na AWS, mas mesmo pra você subir na AWS, ele tem que ser quebrado em chunks pra AWS conseguir aceitar. Eventualmente se a gente quebrar esses chunks antes e conseguir manter esse histó, se a gente quebrar esses chunks antes e conseguir manter esse histórico com a gente, eventualmente a gente consegue economizar espaço, inclusive, porque nesse caso esse serviço provavelmente vai ficar bem caro, né? De uma forma geral, é caro. Então, isso é um ponto de reflexão. Sobre o lance do CloudFront, etc., em relação ao MRU, isso aí é super importante. Por exemplo, eu posso criar, ou num banco de dados, ou posso usar até um banco de dados de chave-valor, que toda vez que eu quero acessar um arquivo, o que eu vou fazer? Um arquivo é ligado a vários chunks. Então, quando eu acabei de subir esse arquivo, o que eu vou fazer? Um arquivo é ligado a vários chunks. Então, quando eu acabei de subir esse arquivo, o que vai acontecer? Na hora que eu pedir para acessar, o meu serviço vai ver quais são esses chunks no banco de dados. O que ele vai fazer? Ele vai fazer o download, vai grudar esses caras e vai devolver. E o mais interessante é que nesse ponto eu não tenho problema de cache com o CDN. Porque os chunks que eu tenho já disponibilizados, eles fazem partes ali de snapshots. Toda vez que eu tiver um arquivo novo, por isso que é, quando você cai no banco de dados, você vai ter os chunks específicos daquela última versão. E aí você pega esses caras pra fazer o download, entendeu? Então você elimina, nesse caso eu acredito que elimina completamente problema de problema de de TTL ou qualquer coisa, porque você sempre vai pegar a última versão. E dá pra ter uma boa otimização se você consegue manter pedaços com chunks você pode pegar um chunk e rodar um um MD5 ou qualquer um um sistema que gera um hash pra garantir que aqueles dados são os mesmos então daí você sai comparando e manda só os caras que são diferenças, alguma coisa meio que parecida com o Git, ou com um sistema como o UFS lá do próprio Docker, que trabalha com sistemas de camada, coisas desse tipo, poderia pensar em alguma coisa não tô falando em nível de tecnologia, mas mais em nível de, como se diz, em nível de de ideia, para conseguir economizar espaço e evitar esses problemas com CDN da pessoa pegar o arquivo colocado. Mas eu acho que a dica principal aí é, é importante sim, e eu acho muito bacana esse fluxo que vocês criaram, porque dá para ver claramente que vocês entendem das URLs assinadas que são importantes pra na hora a pessoa baixar, isso é importante porque na hora que o cara clica, você precisa pegar de alguma forma mas é interessante você ter um serviço, esse serviço gruda os chunks, gera essa URL ou os arquivos ou até mesmo o próprio client pode ter um algoritmo que ele baixa todos os chunks e condensa o arquivo em apenas um, entendeu? Dependendo da situação, dá para fazer alguma coisa desse tipo. Ou seja, ele baixa todos os chunks, gruda na sua própria máquina. Não sei, tá? É só uma... Legal. Pensando alto. Fechou? Fechou, perfeito. Mas é interessante que em relação a serviços a notificações, eu acho que tudo que vocês colocarem, inclusive dos componentes aqui, provavelmente obviamente, né em relação a empresa teria que ver custos, orçamento e tudo mais, mas provavelmente esses serviços aí que você está colocando aí, atenderiam completamente pra conseguir trabalhar a minha única dúvida é no SNS né, porque toda vez que você sobe um arquivo, esse arquivo vai notificar alguém, aí esse alguém vai ter que ser notificado em algum sistema e esse sistema tem que se ligar, entendeu? Eu acho que tem alguma dúvida eventualmente no SNS. E se eu perder aquela mensagem ou qualquer coisa desse tipo tem um pouco o ponto aí de resiliência também não tem um DLQ, alguma coisa assim exatamente isso, então tem alguns pontos aí mas de forma geral tá falando em evento, tá falando em armazenamento tá falando em distribuição com RL fechada então show de bola galera tá falando em armazenamento, tá falando em distribuição, né, com RL fechada, então... Show de bola, galera, show de bola, batam palmas aí pro nosso amigo e pro grupo do Gustavo, botaram apenas o Gustavo na fogueira, os outros caras não apareceram, que vergonha! Não, ligaram a câmera aí, pô! Que vergonha! Mas é isso gente muito obrigado pelo feedback eu tenho aprendido da AWS há algum tempo e é sempre legal a gente entender novas arquiteturas além daquilo que está no nosso plano de estudo mas valeu aí gente, até show cara, show de bola palmas aí pro nosso amigo e agora a gente tem também o grupo do Felipe. Eu não vou mais falar o Felipe, tá? Vou falar o grupo do Felipe, né, Felipe? É, vão ajudar aí. É, vão ajudar. Compartilha aí pra gente, cara. Pronto. Bom, vamos lá. Já gostei do cara porque ele usa tela escura. Brincadeira. Já passou numa parte aí. Vamos lá, cara, manda ver. Bom, a gente não se preocupou aqui em definir tecnologia especificamente, a gente se preocupou mais em definir o fluxo e como que é o comportamento. Então, todo sistema funciona em formato de tenant, onde o tenant, no caso, seria o usuário. Então, informações armazenadas em banco ou no servidor de arquivo, elas vão ser agrupadas pelo tenant, pelo usuário. A gente vai fazer lazy loading dos arquivos, a gente vai sincronizar só os metadados de forma ativa para poder trazer mais performance. A gente pode ter, não está desenhado aqui, mas a ideia é que a gente enviasse os dados, não, os arquivos poucos acessados para um storage mais barato, porque o storage aqui vai crescer muito rápido ao longo do tempo, principalmente porque a gente mantém todas as versões. E aqui a gente poderia adicionar um CDN para poder reduzir a latência, como o Wesley já tinha comentado, isso não seria um problema, porque cada chunk ou cada arquivo é uma identidade única. Ele é uma entidade atômica, ele não muda ao longo do tempo. Então não corre o risco dele estar atualizado ou desatualizado, porque ele é sempre o mesmo. Então a gente separou também em quatro sistemas para a gente ter mais resiliência. A gente tem o sistema de upload, a gente tem o sistema de download, a gente tem o sistema de sincronização e a gente tem o sistema de notificação. Não tem load balancer desenhado aqui, mas em cada um desses sistemas que poderia escalar a gente poderia ter um balanceador de carga. Na questão do upload, a gente faz a quebra dos arquivos em chunks e aí a quantidade de chunks de cada arquivo depende do tamanho, a gente precisaria definir qual seria uma fórmula para chegar em uma quantidade ideal. Esse servidor, a gente pode ter múltiplos servidores de arquivo, pode ser um S3, pode ser um disco mesmo, e a gente fazer gestão. A ideia de ser múltiplos é porque a gente pode salvar os chunks em servidores diferentes, isso vai trazer para a gente muito mais performance, não só na escrita quanto na leitura. Esse serviço de upload vai definir aquela versão do arquivo, através dos metadados que estão salvos no banco de dados, e aí ele publica, por fim, depois que ele termina esse processo, ele publica um evento aqui no nosso sistema de mensageria, para que os outros serviços possam consumir esse evento, essa subida de arquivo, então o sistema de download escuta esse evento, salva na base de dados dele, que tem um arquivo novo disponível. Sempre que o usuário quer baixar um arquivo, ele bate nessa aplicação aqui que faz o download para ele poder validar se esse usuário tem permissão de baixar um arquivo, ele bate nessa aplicação aqui que faz o download para ele poder validar se esse usuário tem permissão de baixar esse arquivo. Ou no caso, eu mando ali um ID de arquivo e o nosso servidor de download retorna uma lista de chunks. E aí o usuário vai poder baixar esses chunks. Então aqui a gente consegue até colocar uma parte de segurança para evitar que um usuário baixe arquivos de outros usuários. Aqui seria o sistema de sincronização. A gente decidiu separar ele mais por questão de alta disponibilidade. Ele só vai armazenar basicamente os metadados do arquivo no banco de dados e é onde os usuários, toda vez que acessa, que abre a aplicação, pode ser um pooling ou um websocket ou qualquer coisa nesse sentido, eles vão estar sempre sincronizando com esse sistema. Então, aqui a gente tem até um pouco de demandas diferentes. Aqui no upload a gente tem CPU e rede, no sistema de download a gente gasta muita rede e disco, já no sistema de sincronização vai ser disparado mais vezes, então ele vai bater mais vezes no banco de dados, mas são sempre requisições pequenas, as respostas são sempre pequenas, porque sempre vai retornar os metadados. Aí retornou, sincronornar os metadados. Sincronizou os metadados com o usuário, se ele vê que ele já lista os arquivos atualizados, quando ele abrir um arquivo, se ele não tiver disponível na máquina, ele bate no sistema de download e baixa a última versão desse arquivo. E dentro dos metadados, a gente vai trafegar ali o nome do arquivo, o diretório completo, o tamanho, a lista de chunks, a versão, a ação que o usuário fez, pode ser excluir, editar ou criar, qual o usuário que fez e alguns outros metadados que possam ser relevantes. E por fim, o sistema de notificação. A gente não definiu o que seria, pode ser SNS, pode ser e-mail, enfim, ele só seria um serviço à parte, ele não teria um banco de dados aqui, porque a princípio, né, porque ele não armazena nada de diferente, né, a ideia é subir um arquivo novo, notificou, depois que está notificado, morreu. E aí a gente não deu tempo de adicionar cache, reds, enfim, mas a ideia seria essa a princípio show, mais alguém do grupo quer colocar? quer falar algum ponto? não precisa pedir permissão, é só sair falando, tá galera? não, só deu pra discutir até aí mas nem show, e qual que foi o ponto que vocês sair falando, tá, galera? Não, só deu pra discutir até aí. Show. E qual que foi o ponto que vocês acham que não tá legal? Porque eu duvido que vocês achem que ficou 100% bom o que vocês fizeram. O que vocês acham aí, se vocês fossem entrevistar alguém, ou se alguém mostrasse isso pra vocês, o que vocês acham que seria um ponto importante de crítica? Crítica, obviamente, no bom sentido, né, galera? Eu acho que fazer essa gestão do servidor de arquivo, como que ele vai escolher esses arquivos e também a resiliência desses servidores. se a gente vai ter por exemplo, réplica de chunks em outros servidores de arquivo a gente não colocou aqui mais alguma coisa, Sérgio? se você tivesse que criticar o próprio system design a definição de cache na frente os próprios load balancers, como já foi comentado, opções de onde a gente vai escrever e ler os arquivos, seja para garantir a resiliência, por exemplo, mesmo no esquema do padrão para pagamentos, né? Se algo está fora do ar, ele escolhe o outro. Caramba. Acho que uma parte aí que ficou também é como o client lidaria com com o upload, se fosse o upload automático ou não, né? O Felipe já comentou sobre o download, né? De sincronizar. Acho que por aí, assim. Tem bastante detalhe. Acho também que faltou, assim, a gente não tá limitando número de uploads ou que seja downloads por vez, né? Então a gente poderia ter uma sobrecarga, muitos usuários subindo vários arquivos grandes ao mesmo tempo. Isso poderia gerar uma sobrecarga muito grande. Claro, aqui o sistema de upload... Mas aí não tem problema, isso aí é, acho que nesse ponto não precisa chegar nesse ponto de detalhe porque começa a entrar mais requisito não funcional e coisas desse tipo, tá? Então acho que esse ponto, acho que não acho que nem é a proposta aí Alguém mais do grupo aí quer falar? Se você estivesse entrevistando alguém ou se alguém chega no seu trabalho e olha isso aí, quais seriam as dúvidas aí? Galera, no chat também? Na autorização do usuário também. Volto. Tá, mas a gente não colocou isso muito nos requisitos ali também, então não se preocupa, foca no documento que eu coloquei. Vou até abrir ele aqui para dar uma relembrada. Essa parte é importante, porque vocês não precisam gastar energia com coisas que não foram... Como é que você vai fazer a gestão de conflitos dos arquivos? Conflito do arquivo? Mas em que sentido? Cada arquivo é atômico. A princípio não teria conflito entre os arquivos. Se eu subo um arquivo com o mesmo diretório, ele só sobe uma versão nova. Eu digo, tudo bem, se você subiu a versão nova mas tem gente que discutiu na outra frente com ter o TTL você já tem a gestão de conflitos em relação às versões dos arquivos que você fez o upload é, e também tem isso aqui pela solução que ele colocou aqui, o arquivo é atômico então, como ele tem um banco de dados, toda vez que subir um novo arquivo, uma nova versão, quando eu bater no serviço de download, ele vai pegar a última versão no banco de dados, onde está apontando para os chunks novos da última versão. Então, não existe conflito nenhum e não tem problema de TTL também. É mais ou menos o que eu comentei no final do Outro Coisa. Então ou menos o que eu comentei no final do outro coisa, então acho que a gente não tem muito problema aí, eu não vejo problema de conflito nenhum o único ponto mesmo é poderia ter algum algoritmo, alguma forma de tentar reaproveitar os chunks, entendeu? isso aí eu acho que é importante o reaproveitamento dos chunks é importante, porque provavelmente vai ter chunk repetido e isso não precisaria ter. Entendeu? Eu acho que... Eu tenho uma dúvida. Faz, total sentido. E o Felipe que falou também, só um segundinho, meu amigo. Sim, sim. Fez sentido. Deu para pegar a ideia do banco de dados com os chunks dos arquivos? Sim, sim. Deu para pegar a ideia do banco de dados com os chunks dos arquivos? Sim, sim. Deu sim. Show. Inclusive aqui dessa forma, a gente consegue, pelo serviço de download, a gente consegue controlar a volumetria de acesso em um arquivo, que a gente poderia usar essa outra informação para poder migrar os arquivos menos acessados para um storage mais barato. E sobre o que você comentou, aqui nesse banco de dados a gente também teria os chunks para a gente poder reaproveitar, a gente poderia adicionar uma informação a mais na base de dados desse serviço, que seria, como você já tinha comentado antes, o MD5 de cada chunk, caso batesse um MD5 ali, ao invés da gente salvar ele, duplicar ele no nosso servidor de arquivo, a gente reaproveita esse chunk, já que ele é atômico também. Tinha alguém que estava querendo falar, eu acho que era o Renato, é isso Renato? Opa, sou eu, sou eu. É uma dúvida até que surgiu aqui no nosso, eu não sei se cabe aqui também, mas, por exemplo, assim, a gente tem um usuário, o usuário começou a fazer upload pelo celular, de repente ele ficou sem internet, assim, eu não sei se isso caberia para o exemplo que a gente tem aqui, tá? Não se preocupar. Porque normalmente, se você cair numa entrevista de System Design nesse tipo de coisa, não está no requisito, o cara não te perguntou ou não te provocou com isso, nem gasta um segundo de, como se diz, para especular como é que poderia ser esse nível de detalhe. A não ser que a pessoa pergunte, cara, como é que vai lidar, por exemplo, com concorrência? Concorrência é importante. Se eu tiver subindo dois arquivos iguais ali exatamente no mesmo tempo, como é que vai lidar com isso? Entendeu? Isso aí é um ponto importante. Subindo os dois, tem dois chunks iguais subindo ao mesmo tempo. Então, os dois, tem dois chunks iguais subindo ao mesmo tempo então, esses pontos em relação a concorrência, eles podem ser um pouco um pouco complexo, por exemplo eu estou subindo dois ao mesmo tempo e literalmente, porque quando a gente faz um request, sempre tem uma que chega antes que a outra, mas como eu tenho clients diferentes, com bandas diferentes por exemplo, os dois arquivos estão subindo simultaneamente. Ou seja, eles estão sendo armazenados em disco ainda, simultaneamente. Qual é o cara que vale? É o cara que ficou pronto primeiro no disco, ou é o cara que foi gravado primeiro no banco de dados? Entendeu? Então, isso são algumas decisões de concorrência que tem que tomar um pouco de cuidado. Fez sentido? Uma dúvida. Pode falar primeiro, depois eu falo aqui. Beleza. Nesse caso, se eu entendi bem, tanto nesse primeiro caso quanto no outro que você citou, a gravação do arquivo num repositório, por exemplo, um bucket, ele seria apenas a fonte de verdade. Porque todas as operações de download olhariam para os chunks que poderiam estar armazenados num banco de dados ali. Não, na realidade não. Os chunks, eles ficam armazenados num banco de dados ali? Não, na realidade não. Na realidade não. Os chunks, eles ficam armazenados num S3 da vida. Tá, beleza. O arquivo, o objeto completo, beleza. Não é o completo. São os pedaços dos arquivos mesmo, tá? Então imagina que eu tenho um arquivo de 10 megas, eu crio chunks de 1 mega, subo os 10 arquivos no S3, e esses 10 arquivos, esses 10 pedaços estão no meu banco de dados. Entendeu? Estão no meu banco de dados? Não. Os metadados dele ficam no meu banco de dados. Meio que como o Felipe colocou ali, chunks URL. Eu colocaria ali como um formato de array, tá? Só pra dizer que tem uma listagem ali. Não necessariamente é URL, né? só para dizer que tem uma listagem ali. Não necessariamente é o URL. Pode ser o nome do bucket, o nome do servidor, mas isso aí é detalhe. Mas o arquivo fixo, eu chamaria... Normalmente, quando falam em armazenamento, chamam de block storage. Ou seja, pode ser qualquer serviço de armazenamento de dados. Ou seja, os arquivos ficam lá. E se você olhar bem, um block storage é um tipo de banco de dados. No caso do S3, ele é um block storage serverless. Mas, no final das contas, não deixa de ser um storage, entendeu? Fez sentido? Perfeito. Eu tenho uma dúvida ainda nessa questão. Não sei se eu posso cortar a frente. Não, não. Bom, galera, vamos falando aí. Todo mundo consegue se virar, eu acho. Sobre a questão de versionar os chunks. Se eu tenho um arquivo muito grande, por exemplo, um giga, gzipado, ele vai ser dividido em diversos chunks menores. Mas se esse arquivo aumenta uma linha ou tem algumas poucas mudanças, acho que todos os chunks deles vão ser alterados consequentemente. Cara, depende muito, novamente, é uma discussão que eu não quero entrar a fundo, porque, inclusive eu não sou especialista nisso, mas existem diversos algoritmos e sistemas que conseguem ver as similaridades desses chunks. Dependendo da situação, num arquivo, quando o cara subir uma nova versão, nenhum chunk vai ser reaproveitado. Mas, eventualmente, dependendo de um tipo de arquivo, alguns chunks podem ser reaproveitados. Somente pelo fato de você tentar reaproveitar e ter ferramentas e algoritmos que tentem ao máximo otimizar isso, dá uma pancada realmente de economia. Pensem mais ou menos como uma imagem de Docker. Ou seja, você tem os layers, e esses layers são totalmente reaproveitados na hora que você está fazendo a criação de uma nova imagem com diversas versões e etc. No caso do Docker é bem explícito do Overlay File System porque cada linha basicamente do Docker File acaba virando um layer. No caso de arquivos é mais complexo, mas provavelmente existem algoritmos e sistemas que conseguem fazer esses tipos de identificação e reaproveitamento. Não sou especialista então não vou me meter a falar, mas de qualquer forma é uma observação importante tentar fazer esse reaproveitamento dos chunks. Pode falar, desculpa. Posso fazer uma colocação, uma experiência minha? A gente rodava marketing em diversas contas no Google e sempre que um site, em contas diferentes, em escritórios diferentes, sempre que uma imagem, um banimento, vinha por uma imagem, todas as contas de escritórios diferentes, de contas diferentes, levavam o mesmo ban. Então, o meu entendimento é que eles, mesmo dois usuários subindo o mesmo arquivo, eles salvam esse arquivo uma vez, eles identificam e salvam apenas uma vez, mesmo sendo de usuários diferentes. É, novamente, é passar o MD5 em todos os chunks e ver se tem repetição. Se tem repetição, não interessa de qual usuário é. O importante é você conseguir fazer os apontamentos. Basicamente é, imagina que eu tenho um milhão de chunks. Não quero saber quem é o dono daquele pedaço, porque é só um pedaço de arquivo binário, no final das contas. Aí, eu subi um arquivo, você subiu um outro arquivo, mas eles têm um chunk em comum, dependendo da situação. Na hora que você subir o seu arquivo, eu vou bater no banco, tem na hora que você subir o seu arquivo eu vou bater no banco, tem algum chunk em comum? Tem, opa, então é isso eu não vou subir, porque esse chunk já está resolvido no meu banco de dados só tem que tomar cuidado aí nesses tipos de casos, se o cara deletar um arquivo tem que ver se esse chunk está sendo utilizado por outro usuário, se tiver utilizado, deleta só na tabela de metadados daquele usuário, porque tem outro usuário utilizando. Então, são pegadinhas, mas é importante você colocar. Eventualmente, você pode reaproveitar chunks de outros usuários também. Dependendo da situação, é bem difícil. Mas, às vezes, você está numa mesma empresa, com unidade de negócio diferente, ou pessoas trabalhando em documentos que foram baseados num mesmo documento, às vezes pode acontecer. Então, pode ser uma possibilidade, sim. Eu tenho uma dúvida. Mais na questão da técnica em si, de usar os chunks para poder fazer essa questão do versionamento, né? No caso, eu entendi bem essa questão. Só que, por exemplo, assim, o Git, ele usa o sistema de diff. Então, você tira a diff dos arquivos, a diff dos documentos, e aí ele estaria armazenando só essas diffs para cada commit, no caso, para cada histórico que ele vai estar mantendo lá. É muito complexo ou talvez não eficiente trabalhar num sistema de armazenar só as diffs dos arquivos, por exemplo, que foram feitos no upload? Cara, honestamente eu não sei. Honestamente, eu não quero nem entrar nessa seara porque eu não sou especialista nessa área. Mas eu acho que pro Sysandesign falando especificamente, o ponto é a gente pode ter o pensamento de tentar reaproveitar esses chunks. A forma de como é implementado isso aí, aí, cara, é uma outra discussão que vai longa, a não ser se na hora do system design a pessoa quiser se aprofundar nisso. Eu vou dar um exemplo para você. Eu conheço um amigo que trabalha no Google. E quando ele foi fazer entrevista no Google os caras começaram a falar exatamente de storage e daí começou enquanto você vai falando, os caras vão aprofundando pra entender, até o momento de você falar não sei qualquer entrevista é assim é sempre tentar chegar ao ponto de fazer a pessoa falar, não sei inclusive você consegue ver até a honestidade da pessoa nesse momento. Porque você sabe quando a pessoa começa a enrolar. Chega um momento que é melhor você falar, cara, não sei. Entendeu? E quando eu não sei, eu já falo de cara. Não sei e ponto. Mas o nível de profundidade foi entrando tão grande que basicamente chegou um ponto no System Design, na entrevista, o cara falar, como que você montaria um S3? Google Cloud Storage. Como que você montaria ele? Como é que você faria o sistema de arquivos? Você trabalharia com os chunks? Como é que isso é formado? Como é que isso é gravado em disco? Quais são os tipos? Cara, vai em nível de hardware, pra vocês terem uma ideia. Entendeu? disco, quais são os tipos, cara, vai em nível de hardware, pra vocês terem uma ideia entendeu, então assim é algo que acaba sendo tão específico que sabe aquela história, se você pegar um engenheiro especialista nessa parada e a gente falar dessa forma o cara fala assim, esse cara não sabe nem do que ele tá falando, o tamanho do problema que ele tá falando, de só ver a similaridade de chunk, entendeu? Então, o interessante nessas, nesses pontos, quando cai, por exemplo, um system design, alguma coisa assim, tô falando de entrevista nesse caso, tá? Mas system design você faz na sua empresa, pros projetos e tudo mais, mas você sempre vai ter que defender, falar pra outros colegas, botar pra discussão, que acaba sendo, entre aspas, uma espécie de entrevista também. Mas, de forma geral, é... Você sempre vai tentando ao máximo descer um nível até a pessoa abrir o bico, entendeu? E é interessante porque tem assuntos que a pessoa pode abrir o bico logo. Por exemplo, eu com certeza na hora que chegasse num nível de especificidade de armazenamento de arquivos eu ia falar, não sei mas daí quando cai num nível de mensageria talvez o meu nível de conhecimento seja maior, quando cai num nível de load balancing, pode ser razoável, então todo mundo tem gaps em áreas, então a ideia ali é a gente chegar exatamente nesses gaps por mundo tem gaps em áreas, então a ideia ali, né, é a gente chegar exatamente nesses gaps, por exemplo, galera, e uma dica, tá, inclusive depois eu vou trazer o System Design que o Fabian fez, tá, mas uma dica que, e no próprio System Design dele não tem muito isso, mas o dele tá mais fácil de entender, sempre, se o seu, se você bater o olho no system design e ficar complicado de você entender o fluxo, refaça. Tá? Por exemplo, eu tô olhando esse system design, você teve que fazer toda uma explicação e na minha cabeça aqui eu tive que fazer uma baita ginástica mental pra conseguir entender essas setas. Então, se em cada seta você, por exemplo, colocar 1, 2, 3, 4, aí eu consigo. O usuário faz o upload. 1, o upload grava no banco. 2, o upload manda pra mensageria. 3, o outro faz escrita. 4, né? Ou 4, 4.1, 4.2 fica mais fácil da pessoa conseguir entender quando você tá fazendo isso com alguém você não faz tudo de uma vez, então quem tá no processo de desenho consegue entender a evolução mas quando o documento fica pronto você olha assim e você fala cara, tá difícil entender, por exemplo nesse caso você colocou um sistema de mensageria, mas provavelmente o sistema de mensageria teria diversos tópicos ou diversas filas. Então, nesse caso, na forma como está aí, aparece que o sistema de notificação vai ler exatamente a mesma fila que o sistema de upload. Na realidade, provavelmente não é isso. O sistema de upload provavelmente vai publicar em uma fila que o sistema de upload. Na realidade, provavelmente não é isso. O sistema de upload provavelmente vai publicar numa fila, vai ter algum processamento, daí o sistema de notificação pega de outra fila, o sistema de download pega de outro lugar, entendeu? Então, provavelmente, sempre quando tiver esses fluxos, inclusive de filas, tentem colocar quais... Não precisa necessariamente colocar qual é de filas, tentem colocar quais não precisa necessariamente colocar qual é a fila, mas mostrar o fluxo do dado entrando e saindo da fila, porque da forma como está aqui tudo estaria numa única fila e se você olhar, na realidade não é tão bem assim, porque enquanto ele está fazendo o upload ainda ele está lendo a sincronização mas não estaria pronto para notificar. Se tudo for disparado ao mesmo tempo, vai dar ruim aqui. Então, é importante o fluxo da fila ficar claro, porque do jeito que está aqui, parece que é apenas uma fila, tá? Então, isso aí é importante colocar. Uma outra dica que eu daria aqui também para vocês é, como nesse caso está muito claro que existem diversos clients, etc, eu faria a divisão muito clara do mundo do server e do mundo do client. Entendeu? Por exemplo, o sistema de notificação notifica o client. O client tem que ter provavelmente um sistema nele de verificação de notificações. Por exemplo, eles podem ter um protocolo ali, um server-centered event, um websocket, o websocket não precisa porque você não tem múltipla fala aí nesse caso. Um server-centered event poderia ser alguma outra forma, entendeu? Então, mostrar essa comunicação um pouco mais clara. Declined server seria mais interessante porque parece que tem serviços do lado do cliente também. porque parece que tem serviços do lado do cliente também, né? Aqui parece ter mais serviços só do lado do servidor. Tá? Faz sentido, galera? Sim. Inclusive, juntar os arquivos do lado do cliente, né? Daria pra representar isso aí. Exatamente isso. E aí, juntar dos lados dos clientes tem também outras dificuldades, por exemplo, você vai fazendo browser como é que você junta mas hoje em dia a gente sabe que browser consegue, você consegue colocar workers ali que o próprio browser consegue fazer isso, entendeu? então assim, cada cada device de client, né, cada client tem a sua peculiaridade aí será que chegaria em algum momento que pra fazer o download, se o client não suporta, teria que ter um serviço que gruda lá no back-end baixa o arquivo e depois que o cara baixou, deleta o arquivo, mas daí nesse caso a latência seria maior, porque você tem que grudar isso do lado do servidor pra depois disponibilizar. Então isso ia ter que ser rodado assíncrono. Então, essa parada fica bem complexa, dependendo da forma como a gente olhar. Alguém tem mais alguma dúvida? Ou quer colocar? O Lucas também tá com a mão levantada, tem o Anderson Eu tenho uma perguntinha rápida aqui, tem uma dúvida que eu fiquei, quando a gente foi fazer o nosso design, não abri a câmera porque eu não tenho aqui, tá pessoal? É, por nada não É, o cara em 2025 falar que não tem câmera é sacanagem. Não, é que eu tô no desktop tô no desktop, o notebook não ficou no serviço tem uma parte ali por exemplo a questão de criar, modificar e excluir principalmente na parte de excluir em nenhum dos dois designs, nem no que a gente fez no nosso grupo eu não sei se precisaria ficar claro ou onde ficou claro a parte de excluir por exemplo eu não consegui encaixar no nosso a gente não conseguiu encaixar e eu não consegui perceber em nenhum dos dois também onde ficaria essa parte. O criar talvez o upload, o upload talvez vai criar, mas a parte do excluir, por exemplo, eu não consegui enxergar no desenho essa parte. Aqui, de fato, não está claro, mas quando o sistema de upload finaliza o processo e publica o evento, ele finaliza o processo e publica o evento, ele está publicando qual a ação desse evento também. Aí no caso de uma exclusão, seria um arquivo, por exemplo, com a ação de excluir, aí o resto dos metadatos não seriam mais relevantes, e aí o sistema de download e de sincronização, eles poderiam apagar o registro do banco, porque eles não são mais relevantes aqui para esses dois serviços. Aquela seta para o upload ali representa o que? Um consumo de uma API, por exemplo, ou nada disso? O upload é só o nome do sistema aqui. O sistema de upload, sistema de download, sistema de sincronização e sistema de notificação. Tá, entendi. Cara, enquanto vocês vão falando, eu vou compartilhar a minha tela aqui. Tá? Eu posso tirar uma dúvida? Claro, vai colocando enquanto eu compartilho aqui. Na real, não é muito sobre esse design em si, é mais sobre aquele ponto que você falou, Wesley, da entrevista ali. Porque eu tive uma situação que ficou na minha cabeça numa entrevista recente, que inclusive foi com o iFood, e que eles colocaram assim, ó, a gente tem ali uma lista de avaliações, né, que você pode ir rolando e vai tendo esse resultado e eu falei assim a gente pode estar paginando aqui e colocar um cache assim assado e eles trouxeram o seguinte problema e eu não soube como responder isso e eu estava pensando nisso esses dias cara, como é que fica o cache quando você pega um cara que tem muito tempo e ele sai rolando sei lá, 10 mil avaliações ali de um restaurante até o final, sabe como é que fica a questão do cash ali que vai sendo armazenado dessas, vamos dizer assim, 10 mil requisições e preenche de repente talvez comece a atrasar outros usuários que estão usando o cache e tal. Tá, cara, vamos fazer o seguinte, porque isso muda bastante o foco do que a gente está colocando. Vamos tentar focar nesse coisa e depois a gente pode falar, mas na realidade, você tem que pensar na estratégia, toda vez que você está falando em cache, você tem que pensar na estratégia toda vez que você está falando em cache você tem que pensar em estratégia de invalidação entendeu? porque no final das contas, você começa a scrollar por exemplo o que vai acontecer ali é, você tem que ter o cache que vai rolar do lado do back-end, você tem o cache do lado do front-end também, entendeu? e o que vai começar a acontecer? Conforme você vai rolando, você vai fazer as requisições, vai cachear aquela parada e no front-end vai acabar acontecendo exatamente a mesma coisa. O grande ponto é que quando o cara acessar aquela parada de novo, ele vai ter que bater no servidor de cache de alguma forma e ali vai ter que bater no servidor de cache de alguma forma e ali vai ter a forma de como aquele cache vai ser invalidado. Normalmente, toda vez que alguém fizer pergunta de cache para você, normalmente ela vai estar ligada a formato de invalidação do cache. Entendeu? Porque é ali que é onde dá o maior problema, porque um monte de usuário começa a cachear, entendeu? E aí esse cache acabou sendo mudado porque mudou uma requisição, uma atualização de qualquer tipo de coisa. Esses formatos de invalidação que geram toda essa confusão e problema de concorrência que pode acontecer. Então, pelo que eu entendi, está mais ou menos ligado com isso. Mas, caras, um dia a gente pode pensar, eu fazer uma aula ou alguma coisa assim, só falando de cash, cara, porque é um assunto, assim, complexo pra caramba e eu teria que entender um pouco melhor, inclusive, o problema. Não sei se eu entendi tudo, inclusive, do que você falou, tá? Mas normalmente, o cara falou de cash pra você, normalmente sempre vai cair no tema invalidação, que é a parte mais, de forma geral, mais difícil, porque existem diversas estratégias ali. Normalmente é ali que o problema vai rolar. Agora, as 10 milhões de requisição, cara, acessou a primeira vez, não existe, vai ter que fazer a chamada também, os próximos usuários que vai acontecer. O problema é esses usuários, de forma muito concorrente, tendo muitas alterações naquilo que você está vendo acabar trabalhando agora, um ponto importante é que eu tenho que voltar no nosso foco aqui mas um ponto importante é que normalmente nesses tipos de caso por exemplo o cara vai lá em restaurantes que normalmente a galera que tá naquela região mais consome então ao invés de ele ficar fazendo um monte de requisição pra pegar cada restaurante etc ele já pode pegar e cachear os 10 ou os 20 primeiros restaurantes por exemplo, Twitter né, Wax. Grande estratégia deles é o seguinte. Sabe a timeline dos usuários? Os caras que são mais conhecidos no Twitter, sei lá, você vai lá, o Elon Musk, porque é dono, tá? Um monte de gente acessa a timeline dele o tempo inteiro. Concorda comigo? Cara, vamos cachear a timeline dele inteira, sei lá, os últimos 50 tweets, entendeu? Todo mundo que bater, vai cair nesse cache primeiro, entendeu? E daí esse cache vai sendo invalidado conforme ele vai postando, então normalmente, você sempre vai ter também, pessoas, usuários, categorias que são mais vistas, entendeu? Então, nesse caso, sei lá, dos restaurantes, provavelmente ele não vai fazer um cache só de uma informação única de um restaurante. Provavelmente ele vai cachear os X primeiros, os tantos primeiros nessas paginações para evitar que toda hora você fique batendo em cada um dos restaurantes. Provavelmente deve ser alguma coisa parecida. Mais ou menos como o Twitter faz, tá? As coisas que são sempre mais acessadas, a timeline já é pronta, cara. Ele não fica consultando tweet por tweet fazendo um tipo de ah, deixa eu fazer uma lista de todos os últimos tweets, entendeu? Eles já cacheiam tudo, que nem página de jornalismo, de jornais cara, ele cacheia já a página inteira, até HTML dependendo da situação, ele cospe da forma mais forte possível eu trabalhei muito com CMS no passado e cara, eu trabalhava muito com cache esse bloco é cacheado, esse bloco não é na hora que você montava os pedaços da página, você grudava, cara, era uma parada muito maluca. Você grudava os pedaços do HTML, jogava pro proxy, e ele juntava tudo pra mostrar pro usuário. Eu trabalhei muito com site com altíssima concorrência, em sites de portais, tipo de jornalismo, cara, é insano o lance de tecnologia de cache. E hoje, naquela época, não tinha tanta ferramenta, então tinha muita coisa que é feito manual. Mas, galera, vamos voltar aqui a... Fez sentido o que eu falei? Sim, fez. Obrigado, na verdade. E sim, eu acho que faz sentido ter uma aula só de cache, porque eu realmente acredito que seja um assunto muito grande ali, né? Cara, é demais, é demais. Eu acho que a estratégia de invalidação de cache poderia ser algo mais focado no que é mais acessado mesmo, né? Que é mais frequente, né? Acho que é MFU, algo assim. E tem um time to live também pra... Ou seja, uma dupla estratégia ali pra poder invalidar o que já tá ali há muito tempo. Show. É, dependendo desse tipo de coisa, não precisa nem TTL dependendo, viu, cara? Se não houve alteração, dependendo da situação... Bom, vamos mudar de assunto do cast, né? Tranquilo. Valeu, obrigado, Nath. Galera, essa solução aqui, quem fez foi o Fabian Hezenkamp, que é o nosso professor do MBA específico de System Design. Galera, uma coisa que eu percebi, eu vi algumas pessoas soltando aqui um Design System. Tome muito cuidado. System Design e design system são coisas diferentes. Normalmente design system, ele é focado em você criar padronizações de front-end pra que você consiga grudar os componentes de uma forma fácil, como se fosse uma biblioteca de estilos que a sua empresa pode ter. Tá? System design é o design de sistema, então tomem cuidado pra falar sempre nesse contexto que a gente tá, em System Design e não Design System, tá? Porque são coisas diferentes e pode gerar confusão realmente, tá? Então vamos lá. Galera, o que que o Fabian fez aqui? Ele fez a separação do mundo do cliente e do mundo do servidor. Tem muita coisa aqui que é bem similar com o que o grupo do Felipe fez. Mas tem algumas coisas interessantes aqui. Que é o seguinte, ao invés de ele ficar necessariamente separando upload e download, a gente tem um serviço específico e eventualmente esse serviço pode ser criado em outros. Mas é importante entender que o contexto aqui desse file service é, qualquer coisa que eu tenho que lidar com arquivo, bate aqui. E aí nesse caso, você pode pensar em download, upload, alteração e qualquer coisa desse tipo. E basicamenteamente o que acaba fazendo, né? você tem um serviço de, sempre vai bater num serviço de sincronização, porque querendo ou não, a ação inicial sempre vai partir do usuário, né? então o que vai acontecer? veio uma alteração ou qualquer solicitação do usuário vai sincronizar pra garantir sempre que você tem, vamos dizer, como se fosse a solicitação do usuário, vai sincronizar para garantir sempre que você tem, vamos dizer, como se fosse uma fila ou um monte de processamento que você vai ter que fazer para garantir qual é a ação que vai acontecer no sistema no serviço de arquivos. Nesse caso aqui, olha que interessante, Felipe, nesse caso, ele também separa isso em os dados com metadados e depois eu vou pegar aqui a estrutura de banco de dados que ele sugeriu mas de forma geral é block storage, banco de dados e não interessa qual serviço se é serverless, se é um sistema de armazenamento interno existem diversas soluções por aí mas de forma geral você grava esses arquivos aí aqui tem algo interessante e é muito parecido com o que o nosso amigo que mostrou as soluções baseadas na AWS colocou em relação ao SNS, porque no caso quando algo entra no S3 ele notifica para o SNS, né? Porque no caso, quando algo entra no S3, ele notifica para o SNS. Mas aqui nesse caso, a gente está falando muito mais de aplicação. Entendeu? Então, esse Watch Service, ele fica vendo se entrou novos arquivos. Então, esse aí que é o grande ponto. Mas não é se um arquivo for persistido. Tem uma diferença grande aí, porque no S3 ele notifica no SNS quando um arquivo é persistido mas um arquivo ser persistido não significa que isso já foi sincronizado, que está no banco de dados que esses arquivos estão prontos para uso ou qualquer coisa desse tipo, ainda mais se você separar em chunks, você vai receber um monte de notificação dos chunks, inclusive aí, tá? Então, esse watch service, ele fica vendo. Tem coisa nova, pronta, completa, no banco de dados aqui? Tem. Então, o que eu vou fazer? Vou pegar isso, vou jogar para uma fila, tá? E aí, caras, depende muito se necessariamente você precisaria jogar numa fila. Por que eu digo isso? Depende muito da abordagem. O que acontece? Hoje em dia, se você ver notificações, existem dois tipos de notificação, conceitualmente falando. Uma notificação que é uma notificação comum, ou seja, que ela fica registrada pra sempre ali na sua lista, e tem notificações time sensitive, ou seja, são notificações que elas têm que ser feitas naquele momento, com toda prioridade no client, pra ele saber que aquilo é importante. O que que acontece aqui? Esse watch service, ele manda pra uma fila e esse notification service, ele pega esses dados de uma fila pra notificar o client. Qual que é a vantagem de colocar a fila aqui nesse momento? Eventualmente, o notification service, ele pode acumular arquivos de notificações que aconteceram e mandar o Notification Service, ele pode acumular arquivos, né, de notificações que aconteceram e mandar a cada tanto tempo, diversas notificações agrupadas numa só, né, ou a cada item que chegou a uma notificação, porque, cara, imagina que você sincroniza e sobe 10 arquivos de uma vez. Será que, por isso que eu estou dizendo, aí é especulação e é coisa que a gente pode continuar numa entrevista. Será que eu preciso receber 10 notificações? Se eu subir, arrastei 10 arquivos de uma vez. Será que não é melhor receber uma única notificação quando os 10 arquivos subirem? Então, depende muito de como você quer trabalhar. A fila aqui, ele garante mais resiliência. Se o client, por exemplo, naquele momento, estiver indisponível de alguma forma, né? O Notification Service, ele pode fazer retries e se o Watch Service ou o Notification Service estiver fora do ar nesse momento, a fila também vai garantir mais resiliência, principalmente nesse caso. O Notification Service ali, eu talvez colocaria um túnel, de alguma forma, um pouco mais persistente, mas provavelmente como o server está conectado com o Notification Service, provavelmente você vai ter que abrir um protocolo, um server sense event, ou alguma coisa assim, para ficar um túnel aberto de conexão. provavelmente você vai ter que abrir um protocolo um server sense event ou alguma coisa assim pra ficar um túnel aberto de conexão e daí a gente acaba entrando em requisito não funcional cara, quantas conexões o notification service consegue aguentar ficar abertas o tempo inteiro com o cara entendeu? Então esse é um outro ponto tá? Mas ali ele garante um pouco de resiliência no caso aqui é no caso do client aqui, basicamente é, você recebeu uma notificação, o que ele vai fazer? Ele vai alterar, ele vai alterar aqui, vai sincronizar com o banco de dados local, caso ele não tenha essas informações, ele vai bater no serviço, para conseguir pegar e vai fazer essas alterações e tem o watch service também, houve alteração dos arquivos, o watch service vai pegar os arquivos alterados e vai mandar esses dados também pro servidor então, alterei esse arquivo aqui o watch service lê que esse arquivo foi alterado, manda para esse serviço específico para que esse serviço mande o upload para sincronizar essa alteração aqui com o serviço aqui. Então, esse aqui é um ponto. Alguém tem alguma coisa que faria diferente? Ficou um pouco mais claro entender dessa forma, inclusive as setas? Aqui não tem um, dois, três, mas está um pouco mais fácil de entender. Mas ainda assim, eu colocaria um, dois, três, quatro, para a pessoa ter uma razão um pouco mais lógica de conseguir entender o fluxo. Ô Wesley, um file service... Pode ir lá, David, depois eu comento. Eu fiquei com uma dúvida, Samuel está falando, eu levantei a mão aí, Wesley, sobre esse 5DB. Considerando que a pessoa pode subir um giga de dado ele vai consumir um giga do cliente lá armazenando coisas, então se o cara for mexendo isso vai tomar um giga dele não necessariamente esse 5DB é um banco de dados local que vai guardar os metadados com a lista de todos os arquivos que foram baixados no client, entendeu? Ou seja, porque localmente no meu client, eu preciso saber quais os arquivos que eu tenho, entendeu? Então eu preciso saber o estado desses arquivos. Então, eventualmente eu tenho que a última sincronização que aconteceu com o servidor foi em tal momento, né? E a última versão desse arquização que aconteceu com o servidor foi em tal momento. E a última versão desse arquivo vai ser mexer nesse arquivo eu tenho que alterar esse syncdb. Eu falei, esse arquivo está alterado e não está sincronizado. Beleza. Aí o coach update service lê esse syncdb e vê, tem algum arquivo que não está sincronizado? Tem, esse aqui. Be, beleza. Daí ele lê esse banco de dados, vai nesse arquivo aqui e manda pro serviço de sincronização e ele fala, olha, vamos sincronizar, beleza, pra sincronizar eu preciso fazer o upload, daí ele faz o upload. Fez sentido? Entendi, então ele é só de metadados, então. É só de metadados, então? É só de metadados, não é o... Porque os arquivos ficam localmente mesmo armazenados. Entendi. Obrigado. Alguém aí? Wesley, o file service, ele não podia avisar direto o watch service? Acho que acabou a operação, por exemplo, postar em uma fila ou alguma coisa e falar, ó, esse cara aqui tá ok, você consegue avisar o pessoal aí? Poderia. E honestamente, tá? Novamente, galera, não fui eu que fiz esse cara. Honestamente, eu não usaria essa abordagem que ele colocou do Watch Service ficar além do banco de dados. Eu usaria, com certeza, usaria a fila aqui, tá? O File Service, sem dúvidas, eu jogaria aqui pra uma fila. É, exatamente nesse sentido, o sync service, pra mim, principalmente nessa sugestão aí do Luiz, ele meio que, na real, meio que fica desnecessário, assim, se você coloca ele meio que pra conectar direto com o web service ali, o sync Service era quase como uma porta de entrar, um API Gateway ali, pras requisições, basicamente. Ele já poderia se conectar direto com o Fire Service nesse caso, não? Honestamente, eu faria a separação, tá? Porque ter um serviço que eu simplesmente consigo de tempo em tempo ficar comparando apenas sincronização porque da mesma forma que o que localmente eu tenho os dados da minha sincronização, eu tenho que garantir que os bancos de dados que eu tenho do que eu tenho dos outros serviços eles estejam ali sincronizados e eventualmente se tiver uma requisição duplicada ou qualquer coisa desse tipo, esse cara ele consegue aliviar um pouco a carga, porque o file service é um cara que ele vai sentar a bunda mesmo de tanto processamento, então houve uma separação aqui dependendo da situação honestamente eu separaria tá, eu separaria mas se alguém me mostrasse o remote update mandando direto pro file service, pra mim também dependendo da situação seria aceitável é que como tem muitos, muita sincronização, entendeu? Então, eu não queria ficar misturando o que é realmente manipulação de arquivo, que no final das contas o file service faz, do que apenas ficar verificando sincronização. Porque isso aqui é uma leitura muito intensiva, principalmente aqui. Então, o file aqui é uma leitura muito intensiva, principalmente aqui, né? Então, o file service, ele é um cara que, ele é bem específico pra lidar, então, tem um pouco de responsabilidade diferente, mas dependendo da situação, você poderia acumular a responsabilidade e se começar a atrapalhar muito aqui, dependendo, você poderia quebrar, tá? Mas não tá errado, tá? Eu, seria totalmente aceitável se mandasse aquela seta direto para o file service o notification service ele atualizaria diversos dispositivos? as versões nos N dispositivos? sim, o que acontece é o seguinte quando o client liga ele abre uma comunicação com o Notification Service. Basicamente é isso, entendeu? Esse aí é o grande ponto. E aí que tem um ponto crítico, se a gente for para requisito não funcional, é, eu tenho que abrir um trilhão de conexão, entendeu? E essas conexões, querendo ou não, elas ficam abertas. Você não vai ficar fazendo, dependendo da situação, long polling ou qualquer coisa desse tipo, porque você ia ter que ficar batendo e você não ia receber muita requisição, você não ia ter também tanto tempo real. Aí tem ponto de custo, qual a tecnologia que você vai usar. Por exemplo, você pode pegar um serviço, sei lá, da AWS, só focado em servidor de WebSockets, onde um conecta em um, outro conecta de outro em coisas desse tipo. Então, depende muito de como que você quer fazer. Honestamente, eu trabalharia aí com Server-Sent Events, com certeza. Eu não usaria nada de WebSocket ou qualquer coisa, porque é um cara notificando o outro, você não precisa de dupla comunicação bidirecional. Mas sim você não precisa de dupla comunicação bidirecional mas sim, você teria um monte cada client tem uma conexão aberta com o Notification Service tem mais mãozinha levantada aí galera? a gente tem umas duas mãos aqui vamos para essas duas a gente já passou um pouco da hora inclusive o Matheus quer colocar alguma coisa? Boa noite, pessoal. Minha dúvida, Wesley, é sobre os arquivos em chunk, né? Que aí até nem tá especificado, mas a ideia seria você salvar os metadados no seu banco local... Ah, eu vou trazer aqui que eu não tinha colocado, tá? Olha aqui, ó. Aqui eu acho que fica um pouco melhor pra entender, tá? Eu tenho o usuário e todos os arquivos dele, tá? Esses arquivos, basicamente, é a lista dos metadados, onde eu tenho o ID, o usuário, quando que ele foi editado, editado por quem, o nome do arquivo, o size e os chunks. Aqui são todos os chunks desse arquivo. E aqui são os snapshots, ou seja, versão 1, versão 2, versão 3. Quais a lista de chunks de cada versão, entendeu? Então, e esses chunks seriam a referência do arquivo, né? É, tudo aqui é metadado, né? Porque o arquivo físico mesmo, ele fica gravado no block storage, né? É, tudo aqui é metadado, né? Porque o arquivo físico mesmo, ele fica gravado no block storage, né? Então, basicamente, ó, ele manda aqui pra file chunks que fica no block storage. Então, aqui é apenas a referência pra onde esse arquivo tá guardado. E aqui, tem um key value store que pode ser bem útil no final das contas, tá? Porque no final das contas, tá? Porque no final das contas, sempre quando eu tenho a última versão ou coisas desse tipo, eu posso ter um cache muito claro, entendeu? O arquivo tal a... esses caras aqui, entendeu? Chave e valor, chave e valor, chave e valor. Esse arquivo aqui, ao invés de ficar batendo num banco de dados relacional, pegando todas as informações todas as horas, entendeu banco de dados relacional pegando todas as informações todas as horas, entendeu? Aqui acabaria funcionando quase como um cache, um Redis aqui funcionaria bem, inclusive. Entendeu? É, então o Mongo também, né? O Mongo é mais pra documentos, né? É, o... É, o Mongo seria mais focado em documentos. Nesse caso, chave e valor aqui serviria muito. Tem o arquivo e links aqui, por exemplo, entendeu? em documentos. Nesse caso, chave valor aqui serviria muito. Tenho o arquivo e links aqui, por exemplo, entendeu? Então... Mas, cara, assim, dá pra fazer totalmente com banco de dados relacional? Dá. É que normalmente aqui acaba sendo mais barato os tipos de consulta, porque você não precisa consultar muitos dados. Mas daria pra fazer de forma geral com tudo relacional também. Ou, dependendo da situação, dariaia pra fazer de forma geral com tudo relacional também, ou dependendo da situação daria também pra fazer tudo com o Mongo tá, o Mongo hoje ele, hoje não, já faz um bom tempo que ele também consegue garantir ESID, né, pra parte de transacional e garantir que tudo tá persistido e garantir a parte de concorrência também, né então esse é um ponto importante eu acho que com esse desenho fica mais claro, né? Chunks, os snapshots são as versões. Eu acho que acaba ficando mais claro como é que é estruturado. Perfeito. Obrigado. Show. E aí a gente tem aí, por último, o Felipe. Fala aí, doutor Felipe. Beleza. Fica uma dúvida só nessa parte aqui na questão de concorrência de upload. Como é que poderia trabalhar nisso em caso de, sei lá, duas pessoas atualizaram o arquivo local e aí acabou que tá tentando subir esses arquivos simultaneamente ali. Cara, seguinte. Minha opinião, e é o porquê, inclusive, tá falando que ESD é o mais importante. Subiu dois arquivos simultâneos. Quem bateu no banco primeiro? E quem bateu no banco por segundo? Entendeu? Bateu no banco primeiro? Cara, nesse momento, tem algum tipo de lock que vai garantir que essa versão é que está subindo. Os arquivos podem subir de forma assíncrona? Podem subir de forma assíncrona. Mas bati nesse banco, eu tenho os chunks e vou guardar. Terminou essa requisição no banco, o que vai acontecer? Começa a outra no banco também. Entendeu? Então, normalmente aí, o lance de consistência acontece nesse caso pelo banco, cara. Porque o banco é a porta de tudo no final das contas, é onde a gente vai bater. Então a gente vai bater sempre na última versão, a gente tenta manter a consistência sempre aí pelo banco. Porque a questão não é o upload simultâneo. A questão é a gravação no banco dizendo que teve o upload. E sempre alguém gravou primeiro que o outro, entendeu? Então eu acho que a grande sacada aí tá no banco de dados. Fechou? Eu ia acabar, Felipe, mas eu acho que é isso. Galera, pra gente não estender mais, deixa eu parar aqui o a coloca, então, pessoal espero que vocês tenham curtido