Conteúdo original em https://twitter.com/zanfranceschi/status/1587431299458813952
Ei dev,
Já ouviu a afirmação "sistemas que escalam de verdade são assíncronos"?
Se essa frase não faz muito sentido pra você, guenta aí que vai fazer ─ vou destretizar essa parada pra você!
cc @sseraphini
↓
Primeiramente, o que são sistemas assíncronos? São sistemas que funcionam de forma dessincronizada. Ou seja, cada pedaço faz uma coisa em uma hora diferente.
Claro que no fim são peças que colaboram para uma causa maior, mas a integração entre essas peças é desacoplada.
Quando falamos de desacoplamento, a gente necessariamente introduz indireção. Ou seja, para desacoplar A de B, precisamos introduzir algo entre os dois.
Existem várias formas de fazer isso e duas super comuns são troca de arquivos e via sistemas de filas. Vamos focar nas filas.
Suave até agora?
Agora vamos falar do motivo de sistemas síncronos serem mais complicados de escalar.
Imagina um sistema composto por 4 aplicações que se integram de forma síncrona ─ via HTTP, por exemplo. A que chama B, que chama C, e D que é chamado por A.
Vamos supor que esse sistema, do jeito que é hoje, suporte até 100 r/s (requisições por segundo). Isso significa que A, B, C e D suportam 100 r/s cada.
A capacidade máxima do sistema é sempre igual a menor capacidade entre as aplicações participantes.
Se precisássemos aumentar essa capacidade para suportar 200 r/s, necessariamente a capacidade de A, B, C e D passariam a ser de 200 r/s cada.
Essa é uma treta clássica de integrações síncronas: tudo precisa ser escalado quando uma coisa precisar escalar.
A questão da capacidade de r/s é apenas um dos aspectos de escalabilidade. Por exemplo, tolerância à falhas tende a ser menor em sistemas síncronos. Se qualquer uma das 4 aplicações falhar, a requisição falha também ─ o sistema como um todo falhou na percepção de quem o usa.
Até aqui, apontei os lados negativos da escalabilidade de sistemas síncronos. Agora é hora de apontar os lados positivos sobre escalabilidade de sistemas assíncronos.
Dá uma olhada nesse diagrama do mesmo sistema hipoteticamente reformulado para ser assíncrono.
Agora, pensando em requisições por segundo com o sistema reformulado para ser assíncrono, a aplicação A é a única que precisa realmente suportar a capacidade definida.
A fila na integração irá agir como um buffer e B/C, e D irão trabalhar conforme suas capacidades individuais.
Outro ponto importante é a tolerância à falhas. Da perspectiva de quem usa o sistema, uma falha em B, C, ou D não será diretamente perceptível e A ainda conseguirá receber e responder as requisições. Bonito isso, né?
Mas não acredite que sistemas assíncronos são mil maravilhas que irão resolver sua vida!
Um sistema assíncrono pode ser muito mais complexo e a experiência de quem o usa pode mudar consideravelmente.
Geralmente, para desenhar sistemas assíncronos, a gente se baseia na experiência requerida do usuário.
P.ex.: talvez reservar um lugar no cinema vire uma tentativa e não mais uma resposta instantânea "deu certo"/"não deu certo". Como esse estado intermediário será tratado?
Aplicações que funcionam fora da percepção imediata dos usuários também podem ter restrições de tempo de processamento. Ainda no exemplo do cinema, se a reserva do lugar fosse na aplicação B, talvez a usuária não queira ficar 2 horas esperando pra saber se a reserva deu certo.
No final das contas, como tudo na vida, o importante é entender os prós e contras de cada abordagem.
A thread ficou longa, mas espero que você tenha conseguido pelo menos desenvolver uma intuição sobre o motivo de sistemas assíncronos escalarem de forma mais fácil e natural.
Como sempre, muito obrigado por ter lido até aqui!
Um beijo pra quem é de beijo ou um abraço pra quem é de abraço. 😗 🤗
Top comments (0)