Até hoje eu consigo me surpreender com quão “novo” é o conceito de filas e troca de mensagens assíncronas para programadores. Hoje eu vou mostrar como esse conceito já está presente na nossa sociedade desde antes do nascimento de Jesus Cristo e você não percebeu ainda.

Mensagens Assíncronas

Na nossa sociedade moderna, mensagens assíncronas acontecem o tempo todo, mas muito antes da existência do computador já poderíamos ver esse tipo de atividade.

Uma carta, nada mais é do que uma mensagem assíncrona, enviada via correios, por exemplo. Mas isso pode parecer “recente” demais.

Desde que evoluímos ao ponto de nos comunicarmos somos capazes de transportar mensagens daqui para lá, e de lá para acolá. Seja para notificar uma outra tribo de que há um predador por perto, até mesmo para escrever em paredes para que outras gerações conheçam a história da sua civilização. Nos últimos 30 anos, temos usado comunicação assíncrona para trocar mensagens fofas e eletrônicas apelidadas de correntes cheias de gifs para os amigos e familiares, como era feito nos anos 2000. Hoje com as mensagens instantâneas, continuamos usando a natureza assíncrona, pra enviar mensagens no telegram, whatsapp etc.

Assim como no contexto de uma chamada telefônica, você não é capaz de atender muitas chamadas ao mesmo tempo, por uma limitação óbvia, você é capaz e já recebe dezenas de mensagens simultaneamente, por email, por SMS, por whatsapp, no telegram, e em push notifications no teu celular. Uma chamada telefônica tem a natureza síncrona. Você precisa estar disponível para atendê-la, ou pelo menos precisa parar tudo ou quase tudo que está fazendo para tal.

É natural que você privilegie mensagens assíncronas a chamadas telefônicas para a maioria das coisas, deixando as ligações estritamente para situações que considera importante.

O que quero trazer para a consciência é que já lidamos com esse tipo de necessidade e aprendemos sobre isso há milhares de anos. O que evolui são os meios, os métodos, mas a natureza assíncrona nos é familiar desde o início dos tempos.

Mas porque isso não é natural quando falamos da comunicação dos nossos projetos? Porque isso não é natural quando falamos de software?

Filas

Um outro conceito que achamos que não conhecemos é o conceito de filas. No dia-a-dia usamos filas para tudo, e em todo lugar.

Quando temos mais atividades que somos capazes de atender, usamos backlogs ordenados ou TODO LIST’s: Filas.

Quando temos uma quantidade de atendentes menor do que a possível quantidade de clientes, o que fazemos? Criamos uma linha de produção baseada em filas. Lembra do caixa da padaria? Da fila do pão? Do caixa e balcão da farmácia?

Em quanto tempo seu documento (RG, CPF, CNH) poderia ficar pronto? Em alguns minutos! Mas isso não acontece por uma pitada de burocracia, mas principalmente por uma demanda maior do que a capacidade de atendimento.

No cotidiano, sempre que queremos atender mais do que somos capazes, enfileiramos as demandas. Naturalmente adicionamos tempo à equação. Nós aceitamos mais do que somos capazes de atender e vamos atendendo no nosso tempo. Quando esse tempo se mostra ineficiente ou inaceitável, adicionamos mais capacidade para atendimento.

No caso de um supermercado, nós movemos mais funcionários para os caixas. A intenção não é ser mais ágil, é entregar maior paralelismo, afim de consumir a demanda mais rápido. Ou tendo um tempo até o atendimento, menor. Mas não há grandes mudanças no tempo do atendimento de cada um.

Agora em 2021, tivemos a vacinação contra a COVID, e a distribuição da população por idade, nada mais é do que uma FILA. Já nos postos de atendimento, a organização de pessoas é feita em FILAS.

Para que não houvesse fila, precisaríamos receber a vacina em casa. Seria insano! Provavelmente usaríamos um meio assíncrono para o envio, como os Correios, por exemplo.

Como há a exigência de um tipo de profissional com certo know how e formação, escasso em relação à demanda, enfileiramos a demanda para conseguir dar conta do recado.

Há milhões de exemplos de cenários em que enfileiramos trabalho, atividades, tempo, prioridades, sonhos, despesas, tudo.

Para qualquer lugar que olharmos, vamos encontrar cenários em que para conseguir atender uma demanda maior do que a capacidade de processamento, enfileiramos a demanda, para diluir a demanda em um espaço de tempo compatível com a força de trabalho que temos.

E porque não pensamos assim no nosso software?

Porque diabos isso não é natural aqui na área de desenvolvimento?

Streams

Se essa estrutura de dados parece nova para você, vou te lembrar do Diário Oficial da União, um Diário que notifica eventos importantes em formato de log. Portarias, normativas etc são notificadas no diário oficial. Em linhas gerais trata-se de um log de eventos governamental. Nele são postados todos os eventos relevantes à sociedade no aspecto legal (saiba mais).

A natureza dos jornais impressos também faz dele streams, principalmente no que diz respeito aos classificados.

Porque é tão disruptivo?

Eu não faço a menor ideia, mas o fato foi que eu me deparei com esse conceito de fato em 2013. Até então, sabia da existência, mas não havia tido necessidade até então. Ou seja, em 11 anos de carreira eu não precisara lidar com isso em um software até então. Pelo menos não diretamente.

Eu acho que isso traz pistas para o fenômeno. Hardware é cada vez mais barato. Desenvolver de forma síncrona é mais intuitivo. Distribuir aplicações é uma prática não recomendada até que se precise de fato distribuir. E por causas óbvias e naturais, passamos anos pensando de forma síncrona, nos esquecendo de como o mundo à nossa volta pode nos dar pistas sobre como resolver soluções tecnológicas.

Na Petrobras, de 2002 a 2005 o mais comum era o desenvolvimento de CRUD’s. Eu tive a sorte de ver outros tipos de projeto, como interpretação de código e análise de sintaxe, mas ainda assim, era para analisar… … … CRUD’s que os outros faziam. De 2005 a 2007 quase que todo o tempo eu estava alocado em um cliente para a construção de um ERP para Seguros, enfim CRUD’s! Mas agora com chatas e complexas regras de negócio, mas ainda assim a maior parte do projeto era CRUD. Existiam até os CRUD’s dinâmicos, mas ainda assim eram CRUD’s.

No final das contas eu acredito que os primeiros anos de carreira da maioria dos dev’s os faz entrar em projetos menores, empresas menores, com demandas que facilmente são atendidas aumentando CPU e Memória afim de atender sincronamente mais usuários.

Embora não faça sentido no mundo real, essa parece ser a realidade do mercado de TI.

No mundo real, seria como se um mercadinho pequeno disponibilizasse um funcionário para cada cliente que estivesse dentro de sua loja, enquanto esse mercadinho não crescesse o suficiente para ter um caixa.

Falando assim, fica óbvio o quanto essa parece ser uma decisão ruim, mas por conta do que citei acima, quando falamos em software, essa verdade não é tão óbvia assim.

A virada

Com a adoção de microsserviços sendo encarado como default para cada vez mais cenários, fica óbvio que soluções que atendiam monolitos com pouca demanda por escala, não atendem o novo modelo.

Com a distribuição de aplicações em serviços menores, o desenho assíncrono entra como solução para diversos novos problemas, inseridos pela natureza da comunicação remota. Se queremos independência, temos de lidar com tudo que faz nossos clientes pararem, e se levarmos ao pé da letra, o curso seria infinitamente absurdo, caso não usássemos mensageria. A garantia de executar depois, e não necessariamente agora, te tira de um cenário absurdamente complexo, para um cenário fácil, tranquilo de se lidar.

Entender esses fundamentos salvam seu dia, seu mês, seu projeto.