A troca que você está realmente fazendo

Desenhe as caixas de um deploy Rails convencional e aparecem quatro. Uma camada web roda o Puma. Uma camada de workers roda o Sidekiq. Um Redis é o que os workers consultam, e um Postgres guarda os dados. São quatro coisas que podem cair, quatro versões para acompanhar e quatro rotinas de backup. São também quatro assuntos que alguém novo precisa aprender na primeira semana.

Agora desenhe esta aplicação. Na parte que interessa a este curso, há um container de Postgres e um container da aplicação. Dentro do container da aplicação, o Puma roda o servidor web e o supervisor de jobs na mesma árvore de processos. Jobs, cache e pub/sub moram todos no Postgres. O config/deploy.yml diz isso numa linha:

# No separate job container: run Solid Queue inside Puma.
SOLID_QUEUE_IN_PUMA: "true"

Quatro caixas viraram duas. Essa é a Solid stack. O curso de nível Pleno "Solid Queue: apoiado em banco de dados", o curso de nível Júnior "Solid Cache: cache no banco de dados" e o curso de nível Pleno "Solid Cable: escala" mostraram como cada peça funciona. Este curso pergunta se você deve fazer isso. É outra pergunta, com respostas diferentes conforme quem pergunta.

É uma decisão, não uma funcionalidade

Ninguém adota a Solid stack porque uma chamada connects_to é elegante. Adota porque responde por alguma coisa. Pode ser uma conta que chega todo mês, um alerta que toca de madrugada ou um plano de contratação que precisa formar alguém capaz de operar aquilo. A Solid stack desloca custo entre essas três coisas. A habilidade toda está em ver para que lado ela desloca no seu time.

O que você ganha é subtração. Um modelo de durabilidade em vez de dois, e um procedimento de backup e restauração. Um conjunto de strings de conexão, um sistema para monitorar, uma curva de capacidade para planejar e uma coisa para aprender. Sem o Redis, some também toda pergunta que começa com "peraí, isso está no Redis ou no Postgres?"

O que você paga é concentração. O polling de jobs, as leituras e escritas de cache e as inserções de mensagens de pub/sub rodavam em hardware que não era o seu banco. Agora rodam em hardware que é. A carga não desapareceu. Ela foi para o componente cuja falha já era a pior falha que você tinha.

Diga o teto em voz alta

Um padrão que ninguém pode contestar é moda, e não escolha de engenharia. O Solid Queue faz polling numa tabela com FOR UPDATE SKIP LOCKED. É um bom mecanismo, e continua sendo uma tabela, num disco, com um índice e um write-ahead log. O Redis responde da memória. A partir de certa vazão, a diferença deixa de ser acadêmica e aparece no seu gráfico de latência. Parte deste curso é achar onde fica esse ponto para uma carga específica, e conseguir dizê-lo sem hesitar.

Os engenheiros que erram nas duas direções são os mesmos. Um grupo adota a Solid stack num sistema que precisa de uma fila dedicada e passa um trimestre descobrindo isso. O outro mantém um Redis, uma camada de workers e um plantão para uma aplicação que dispara quatrocentos jobs por dia. Os dois falharam no mesmo teste: escolheram uma arquitetura sem nomear a carga para a qual ela serve.

O que é verificado aqui, e o que não é

Os exemplos deste curso saem deste repositório, porque esta aplicação roda a stack inteira. O Gemfile declara solid_cache, solid_queue e solid_cable. O config/cache.yml, o config/queue.yml e o config/cable.yml existem e estão ligados. Em produção, dois dos três papéis apontam para o banco principal e um não, por um motivo escrito como comentário no arquivo de configuração. Você vai ler tudo isso.

O que este curso não vai fazer é fingir que uma plataforma de ensino pequena prova alguma coisa sobre um sistema que processa cinquenta mil jobs por minuto. Uma configuração real, pequena e rodando vale mais do que uma grande e hipotética, desde que ninguém diga que são a mesma coisa.

Para onde este curso vai

A lição 2 defende a consolidação com toda a força que ela merece. Ela cobre o que some da sua superfície operacional e por que "menos peças móveis" é um argumento real de engenharia, e não um slogan.

A lição 3 faz a defesa contrária, com a mesma força. Ela cobre quatro cargas em que um Redis separado ou uma fila dedicada é a escolha certa, e como reconhecê-las antes de se comprometer.

A lição 4 cobre o raio de impacto e o orçamento de conexões. Ela pergunta o que acontece quando fila, cache e pub/sub caem todos no mesmo Postgres, e como contar as conexões antes que a produção conte por você. É nela que está o desafio de código do curso.

A lição 5 cobre a operação: backup, restauração, migrations, monitoramento e planejamento de capacidade. Tudo isso muda de forma quando quatro sistemas viram um.

A lição 6 fala de dinheiro, com honestidade. Ela trata do formato da conta, e não do preço de fornecedores, incluindo a parte que é salário de engenheiros, e não infraestrutura.

A lição 7 é o caminho de migração para um time que já usa Redis, mais o lugar do Kamal e do Thruster no mesmo argumento.

Comece pela defesa da consolidação. Ela é mais forte do que o marketing faz parecer, por um motivo específico. O que ela remove não é um servidor. É uma categoria de pergunta que ninguém no seu time vai precisar fazer de novo.