Escalabilidade

Ruby escala?

Essa é uma das discussões mais clássicas no mundo da programação. Geralmente, quando as pessoas dizem que "Ruby não escala", elas estão se referindo a uma combinação de fatores técnicos e históricos, mas a realidade é um pouco mais sutil.

Aqui vão os principais motivos por trás dessa fama:

1. O Global Interpreter Lock (GIL)

O principal "vilão" técnico é o GIL. Ele é um mecanismo no interpretador padrão do Ruby (MRI) que impede que mais de uma thread execute código Ruby ao mesmo tempo em um único processo.

Consequência: Mesmo que seu servidor tenha 32 núcleos de CPU, um único processo Ruby não consegue aproveitar todos eles simultaneamente para tarefas computacionais pesadas.

Contorno: Para escalar, desenvolvedores Ruby costumam usar múltiplos processos (com ferramentas como Puma ou Unicorn), o que consome muito mais memória RAM do que o modelo de threads de linguagens como Go ou Java.

2. Consumo de Memória e Velocidade

Ruby é uma linguagem de altíssimo nível, focada na felicidade do programador. Isso tem um preço:

Uso de Memória: Objetos em Ruby são "pesados". Aplicações grandes em Ruby on Rails tendem a consumir muito mais RAM do que equivalentes em Node.js ou Rust.

Performance Bruta: Por ser interpretada e extremamente dinâmica, o tempo de execução de cálculos complexos é maior do que em linguagens compiladas.

3. O "Fator Twitter"

Alguns se lembram que o Twitter começou com Ruby on Rails e depois migrou partes críticas para Scala e Java. Esse caso ficou muito famoso e criou o estigma de que o Ruby "bate no teto" quando o tráfego se torna gigantesco.

Porém... Ruby escala sim!

Dizer que Ruby não escala é, tecnicamente, um exagero. Grandes empresas provam o contrário:

Shopify: Processa bilhões de dólares em transações usando um dos maiores monolitos de Ruby on Rails do mundo.

GitHub: Quase toda a plataforma é construída sobre Ruby.

Airbnb: Também cresceu e se manteve por muito tempo na base do Ruby.

A diferença é que escalar Ruby custa mais caro. Você precisa de mais servidores e mais memória para aguentar o mesmo volume de requisições que uma linguagem mais performática aguentaria com menos recursos.

Em resumo a performance é sim mais lenta que linguagens compiladas (Go, Java).

O GIL dificulta o uso eficiente de multi-core em um único processo e o custo exige mais hardware (infraestrutura) para escalar horizontalmente.

A produtividade é imbatível para criar produtos rapidamente mas no final das contas, para 99% das empresas, o gargalo não será a linguagem, mas sim o banco de dados ou a arquitetura do sistema.

Node.js é Single-Thread, e ela escala então: O que determina se uma linguagem escala ou não?

O Node.js escala muito bem, mas ele faz isso de uma forma diferente de linguagens tradicionais como Java ou C#.

O que determina se uma linguagem "escala" não é apenas a velocidade bruta ou quantas threads ela tem, mas sim como ela lida com a espera e como ela aproveita o hardware.

O que determina a escalabilidade são três pilares:

Modelo de Concorrência: Como a linguagem gerencia múltiplas tarefas ao mesmo tempo (Threads vs. Event Loop).

Eficiência de I/O (Entrada e Saída): O quão bem ela lida com tarefas que dependem de rede, banco de dados ou arquivos sem "travar" o processador.

Facilidade de Escalonamento Horizontal: O quão simples é rodar 10 ou 100 instâncias da mesma aplicação lado a lado.

E então, como Node.js escala sendo Single-Thread?

O Node.js usa um modelo chamado Single-Threaded Event Loop.

Vamos a metáfora do garçom:

Em linguagens Multi-thread, se um cliente pede um prato que demora, o garçom fica parado na frente da cozinha esperando o prato ficar pronto antes de atender o próximo. Para atender mais pessoas, você precisa contratar mais garçons (mais threads/memória).

No Node.js, o garçom anota o pedido, passa para a cozinha e imediatamente vai atender outra mesa. Quando a cozinha termina, ela "avisa" o garçom, e ele entrega o prato no primeiro intervalo que tiver.

Por isso o Node.js escala: Ele é extremamente eficiente para aplicações que fazem muitas operações de rede (APIs, Chats, Streaming), pois a "thread" nunca fica parada esperando o banco de dados responder.

Comparativo de Estratégias de Escala

Mas quando o Node.js "bate no teto"?

O Node.js sofre quando você precisa de processamento pesado de CPU (como edição de vídeo ou cálculos matemáticos complexos). Como só existe um "garçom", se ele começar a cozinhar (processar) em vez de apenas anotar pedidos, ele para de atender as outras mesas e o sistema trava.

Para resolver isso e usar todos os núcleos do processador, o Node.js usa o módulo Cluster ou ferramentas como o PM2, que basicamente criam uma cópia do processo para cada núcleo da sua CPU.

E o que são o Event Loops?

Para entender a diferença entre Threads e Event Loop, imagine que você está gerenciando uma central de atendimento. Existem duas formas principais de organizar o trabalho:

1. Modelo de Multi-Threads (O exército de atendentes)

Imagine que cada cliente que liga é atendido por um funcionário exclusivo.

Como funciona: Se 10 pessoas ligam, você precisa de 10 funcionários. Se um cliente pede para o atendente esperar enquanto ele procura um documento (isso é o equivalente a uma consulta ao banco de dados ou leitura de arquivo), o atendente fica parado, segurando a linha e sem fazer nada, apenas esperando.

Vantagem: Se um cliente tem um problema muito complexo que exige muito raciocínio (processamento de CPU), ele não atrapalha os outros, pois cada um tem seu próprio atendente.

Desvantagem: Funcionários custam caro (memória RAM). Se 10.000 pessoas ligarem ao mesmo tempo, você precisaria de 10.000 funcionários, o que quebraria a empresa. Além disso, gerenciar muitos funcionários conversando entre si pode gerar confusão (deadlocks e race conditions).

2. Modelo de Event Loop (O atendente multitarefa)

Imagine que existe apenas um único atendente extremamente rápido.

Como funciona: Ele atende a ligação, anota o pedido e, se o cliente diz "espere um pouco", o atendente diz "me ligue de volta quando estiver pronto" ou "anotei seu número, te ligo quando o documento chegar" e imediatamente pula para a próxima ligação.

Vantagem: Com apenas um atendente, você consegue gerenciar milhares de chamadas, porque ele nunca fica parado esperando. Ele só gasta tempo "atendendo" (executando código) e delega a "espera" para outros sistemas (como o sistema operacional ou o banco de dados).

Desvantagem: Se um único cliente fizer uma pergunta que exige que o atendente faça um cálculo matemático de 10 minutos na cabeça dele, ninguém mais é atendido. A fila inteira trava porque o único atendente está ocupado processando.

Resumo Comparativo

Qual escolher?

Se o seu sistema vai fazer muita conta (ex: inteligência artificial ou criptografia), as Threads são melhores.

Se o seu sistema vai lidar com milhares de usuários fazendo requisições simples ao banco de dados (ex: redes sociais, e-commerce), o Event Loop escala de forma muito mais barata e eficiente.

Voltando ao papo de escalar...

Já que você viu que o Node.js "finge" ser mono-thread mas usa a Libuv (que tem um pool de threads escondido para tarefas pesadas), a pergunta que fica é:

Se o Node.js consegue escalar tão bem usando esse truque, por que o Ruby não fez o mesmo?

A resposta é que o Ruby nasceu para ser simples e legível para humanos, enquanto o Node.js nasceu (em 2009) já focado exclusivamente em resolver o problema de conexões simultâneas.

Você prefere uma linguagem que te dê produtividade máxima (escrever pouco e fazer muito) ou uma que te dê controle total sobre como os recursos do computador são usados?

E escalar horizontalmente afinal, o que isso significa?

Essa é uma confusão muito comum, especialmente com a popularidade do Docker e do Kubernetes, abaixo explico a diferença entre o conceito e a ferramenta.

1. Escalar Horizontal vs. Vertical

Imagine que você tem um caminhão carregando caixas.

Escalar Vertical (Scale Up): Você troca o motor do caminhão por um mais potente e aumenta a carroceria. É uma máquina só, cada vez maior.

Escalar Horizontal (Scale Out): Você contrata mais caminhões idênticos. Se um quebrar ou a carga aumentar, você coloca mais um na estrada.

Quando você diz que vai "subir mais Pods", você está escalando horizontalmente.

2. "Sem aumentar o hardware físico"?

Aqui está o ponto principal: Eventualmente, você precisará de mais hardware físico.

Se o seu servidor (Node/Cluster físico) tem 16GB de RAM e cada Pod consome 2GB, você consegue subir 8 Pods.

Se você precisar de 20 Pods, você terá que adicionar mais RAM ao servidor atual ou (o mais comum no escalonamento horizontal) adicionar um novo servidor ao seu cluster.

A vantagem da escala horizontal é que você pode espalhar esses Pods em 10 máquinas baratas em vez de comprar uma única máquina caríssima que pode falhar e derrubar tudo.

3. Mas só é possível escalar usando containers?

Na verdade não. O conceito de escala horizontal existe muito antes do Docker.

Antes dos containers e Pods, fazíamos assim:

Virtual Machines (VMs): Você criava uma imagem da sua máquina Linux com o Ruby/Node instalado e subia 10 instâncias na AWS.

Bare Metal: Você comprava 10 servidores físicos, instalava tudo neles e colocava um

Load Balancer (como o Nginx) na frente para distribuir os usuários entre eles.

E por que usar Containers/Pods?

Usamos containers porque eles tornam a escala horizontal muita mais rápida e barata:

Isolamento: Você garante que o Pod 1 não vai interferir no Pod 2.

Velocidade: Subir um container leva segundos. Subir uma Máquina Virtual (VM) ou ligar um servidor físico leva minutos.

Eficiência: Você consegue "espremer" vários containers dentro de uma mesma máquina física, aproveitando cada gota de CPU e RAM disponível.

O papel do Load Balancer

Para escalar horizontalmente (seja com Pods, VMs ou servidores físicos), você obrigatoriamente precisa de um Load Balancer. Ele é o "guarda de trânsito" que recebe o acesso do usuário e decide para qual Pod enviar aquela requisição.

Resumo

Escalar Horizontal: Adicionar mais instâncias (Pods, máquinas, processos).

Hardware: Você escala horizontalmente dentro do hardware que tem até ele acabar; depois, adiciona mais hardware (nós/máquinas) ao cluster.

Containers: São apenas a forma mais moderna e eficiente de fazer isso, mas não a única.

Mas... não tem milagre. Posso ter problemas de concorrência ou duplicidade de registros usando vários Pods ou mesmo várias VMs com a mesma aplicação

Não existe bala de prata. Escalar horizontalmente resolve o problema de performance, mas cria uma categoria inteira de novos problemas chamados Sistemas Distribuídos.

Quando você tem 10 Pods rodando, eles não sabem da existência um do outro. Se você não cuidar da lógica, o "milagre" vira um pesadelo.

Aqui estão os três problemas clássicos que você pode enfrentar:

1. Condição de Corrida (Race Conditions)

Imagine um sistema de saldo bancário. O usuário tem R$ 100.

Pod A recebe uma requisição para sacar R$ 80. Ele lê o banco: "Saldo é 100".

No mesmo milissegundo, o Pod B recebe uma requisição para sacar R$ 50. Ele lê o banco: "Saldo é 100".

Os dois aprovam o saque e atualizam o saldo. No final, o usuário sacou R$ 130, mas o saldo final pode ficar como R$ 20 ou R$ 50, dependendo de quem gravou por último.

Como resolver: Você precisa usar Locks no banco de dados (Optimistic/Pessimistic Locking) ou filas de processamento (Redis/RabbitMQ) para garantir que certas operações sejam atômicas.

2. Duplicidade de Registros

Se o seu código gera um ID único baseado no tempo da máquina (timestamp), e dois Pods geram um registro no exatíssimo microssegundo, você pode ter IDs duplicados.

Como resolver: Usar UUIDs (Identificadores Únicos Universais) ou bancos de dados que garantam a unicidade através de chaves primárias e índices únicos.

3. O Problema da Sessão (Sticky Sessions)

Se um usuário faz login no Pod A, os dados da sessão dele estão na memória RAM do Pod A.

Se a próxima página que ele clicar for direcionada pelo Load Balancer para o Pod B, o Pod B vai dizer: "Quem é você? Não te conheço". O usuário será deslogado.

Como resolver: Aplicações escaláveis precisam ser Stateless (sem estado). Você nunca guarda nada na memória do servidor. A sessão deve ser guardada em um lugar compartilhado, como um Redis ou via JWT (tokens assinados no lado do cliente).

O programador precisa mudar o "chip" mental de:

De: Vou salvar esse arquivo na pasta /uploads

Para: Vou salvar no S3 (Cloud Storage), porque o outro Pod não enxerga meu disco local.

De: Vou criar uma variável global para contar os acessos

Para: Vou usar um contador no Redis, porque cada Pod tem sua própria variável global

Resumo:

Escalar horizontalmente exige que sua aplicação seja um "processo descartável". Se você deletar o Pod agora e subir outro, nada deve ser perdido. Se você tem arquivos locais ou variáveis em memória que importam, sua aplicação não está pronta para escalar horizontalmente.