Qual banco a Netflix, o Instagram e o X realmente usam? Cassandra, PostgreSQL, Manhattan — e o mito do Redis

Pergunta que volta o tempo todo em entrevista, thread e debate de arquitetura: qual banco a Netflix usa? E o Instagram? E o Twitter/X? A resposta curta que circula na internet quase sempre mistura três coisas diferentes. Redis vira “o banco do Twitter”. Cassandra vira “NoSQL genérico”. PostgreSQL no Instagram vira fato eterno, como se a aquisição pela Meta não tivesse acontecido.

O erro não é só o nome errado. É tratar banco como logotipo. Cassandra, PostgreSQL, MySQL, Manhattan, ScyllaDB e DynamoDB não são substitutos um do outro. Cada um nasceu para um padrão de acesso. A Netflix não “escolheu NoSQL”. Ela modelou serviços com chave conhecida, escrita pesada e a exigência de um nó poder cair sem derrubar assinatura e billing. O Instagram não “foi fiel ao Postgres”. Ele recusou trocar o modelo relacional e inventou um jeito de fatiar o mesmo Postgres em milhares de pedaços. O Twitter não “usou Redis”. Ele construiu um key-value distribuído porque MySQL e depois Cassandra não cobriam o núcleo em tempo real do jeito que o produto precisava.

Este texto é sobre isso: o que cada banco realmente é, qual problema a solução resolve, e por que a mesma empresa quase nunca vive de um motor só.

Três camadas que a internet mistura

Quando alguém pergunta “qual banco a empresa X usa”, quase sempre está falando de três sistemas ao mesmo tempo:

• Banco operacional. Fonte da verdade do produto: usuário, assinatura, post, tweet, mensagem, like, cobrança. Se esse bicho perder dado, o produto mente.
• Cache. Cópia quente para não bater no operacional a cada request. Redis, Memcached, timelines montadas em memória. Pode sumir. O sistema tem de saber reconstruir.
• Analytics e mídia. Iceberg, warehouse, object storage, CDN. Guardam histórico, vídeo, métrica. Não respondem o “qual é o e-mail desse usuário agora”.

O restante deste artigo fala do primeiro. Cache entra só para desfazer o mito do Redis no Twitter. S3 e Iceberg entram só quando a própria Netflix os cita ao redor do Cassandra.

Um mapa rápido, antes de abrir cada motor:

O que esses bancos realmente são

Antes do nome da empresa, vale o modelo. Sem isso, “Netflix usa Cassandra” vira figurinha.

PostgreSQL e MySQL são bancos relacionais. Você descreve tabelas, chaves estrangeiras, índices e invariantes. A unidade de verdade é a transação: ou o conjunto de writes entra, ou nada entra. Consulta é SQL. Você pode perguntar coisa que não previu no dia 1, desde que o dado esteja lá e o índice ajude. O preço clássico: escrita converge para um primário. Dá para escalar leitura com réplicas. Dá para escalar escrita só fatiando o dado — sharding à mão, Citus, Vitess, Docstore, schemas como o Instagram fez. Sem esse fatiamento, um dia o primário satura. MVCC no Postgres (e InnoDB no MySQL) deixa leitura e escrita conviverem, mas gera versões antigas, vacuum/purge e dor quando o write explode.

Apache Cassandra é um wide-column store distribuído. Não existe um primário dono do cluster. Os nós formam um anel. Cada linha tem uma partition key; um hash dessa chave decide em qual nó o pedaço mora. Você replica o pedaço em N nós (replication factor) e escolhe quantos precisam concordar na leitura e na escrita (ONE, QUORUM, ALL). O caminho de write é feito para não parar: commit log + memtable na RAM, depois flush para SSTables no disco, compactação depois. Não há JOIN no sentido SQL. Não há transação multi-partição do jeito que o Postgres oferece. Você modela a tabela a partir da query que já conhece. Se a query muda, muitas vezes a tabela muda. Em troca, o cluster cresce colocando máquina, um nó pode morrer, e a escrita pesada não precisa passar por um único rei.

ScyllaDB fala o protocolo e o modelo do Cassandra (CQL, partição, clustering key). A diferença é o motor: C++, um shard de dados por core de CPU, sem garbage collector da JVM. Para o Discord, isso não foi detalhe cosmético. Pausa de GC e partição quente no Cassandra antigo viraram latência em cascata no cluster de mensagens. Trocar o motor, mantendo o modelo, foi mais barato do que redesenhar o produto em SQL.

DynamoDB é o primo gerenciado da mesma família do paper Dynamo da Amazon: key-value / documento, partição pela partition key, operação feita pela nuvem. Você não monta anel, não compacta SSTable, não escolhe rack. Paga por unidade de leitura/escrita e pela modelagem certa da chave. Hot key dói igual. Scan dói igual. A vantagem é não virar time de Cassandra.

Redis é estrutura de dados em memória, com persistência opcional. Serve como cache, lock, fila leve, ranking, sessão, timeline quente. Não substitui o banco operacional só porque “aguenta QPS”. Se o processo morre e o AOF/RDB não é o contrato do produto, você perdeu fonte da verdade. Gigantes usam Redis o tempo todo. Quase nenhum deles diz que o tweet, o post ou a fatura nascem lá.

RocksDB nem é um banco de rede. É um storage engine embutido, log-structured merge-tree, otimizado para SSD. Você não conecta um cliente RocksDB na porta 5432. Você embute a biblioteca dentro de um serviço. Manhattan faz isso. MyRocks (MySQL com RocksDB no lugar do InnoDB) faz isso. Vários key-values internos da indústria fazem isso. Quando um post de engenharia diz “adotamos RocksDB”, está falando do disco, não da API que o app vê.

Em cima desses motores, as empresas grandes quase sempre colocam uma solução: um produto interno que esconde o cluster. Manhattan é isso no Twitter. Vitess é isso no MySQL do Shop app da Shopify (e nasceu no YouTube). Docstore é isso no Uber, com MySQL por baixo. TAO é isso no grafo da Meta, com MySQL por baixo. Sem essa camada, o app teria de saber shard, failover, membership e às vezes até o formato do SSTable.

Netflix: Cassandra como sistema operacional de escrita

A Netflix é uma das maiores usuárias de Apache Cassandra do planeta, e não por nostalgia de 2012. Em maio de 2026, o próprio Tech Blog escreveu que o Cassandra alimenta aplicações críticas: Member, Billing, Recommendations, Subscriptions e vários outros serviços. O artigo é sobre movimento de dados Cassandra → Iceberg, mas a frase que importa para esta discussão está no começo: esses casos de uso são mission-critical e passam pelo Cassandra.

Por que Cassandra e não um Postgres gigante? Porque o perfil casa com o anel. Cadastro de membro, estado de assinatura, fatura, sinal de recomendação: acesso quase sempre por chave (usuário, conta, título), volume enorme de escrita, várias regiões, e a regra de ouro de streaming — um datacenter doente não pode apagar a Play. Relacional com primário único pune exatamente isso. Você escala leitura com réplica. Escrita continua num gargalo. Failover de primário é evento. No Cassandra, você coloca nó, replica o token range, e a aplicação continua falando com o cluster.

        Cassandra Cluster (Netflix)

┌──────┐ ┌──────┐ ┌──────┐
│Node 1│ │Node 2│ │Node 3│
└──────┘ └──────┘ └──────┘
   │        │        │
┌──────┐ ┌──────┐ ┌──────┐
│Node 4│ │Node 5│ │Node 6│
└──────┘ └──────┘ └──────┘

partition key  ->  nó dono + réplicas
consistência   ->  ONE / QUORUM / ALL
write path     ->  commit log + memtable + SSTable

Isso não significa que o engenheiro da Netflix escreve CQL cru o dia inteiro. Com o tempo, o time criou abstrações em cima do Cassandra: key-value, série temporal, grafo. Cada uma sabe o data model e esconde o jeito certo de particionar. O backup sai do nó para o S3 via sidecar. Jobs de movimento leem esses SSTables e despejam no Iceberg para analytics. Data Bridge orquestra milhares desses jobs. Ou seja: Cassandra é o operacional; Iceberg é o analítico; S3 é o seguro. Três sistemas, três contratos. Quem olha o S3 e diz “a Netflix não usa banco” está olhando o cofre e ignorando o caixa.

O que Cassandra não resolve bem, e a Netflix convive com isso: query ad hoc, relatório do tipo “me dá todos os usuários cujo plano mudou na terça e que assistiram terror”, join entre entidades que não foram desnormalizadas na mesma partição. Por isso existe movimento para Iceberg. O operacional responde o caminho quente. O warehouse responde a pergunta que ninguém modelou ontem.

Se você está escolhendo banco para um SaaS com billing, ACL, relatório e um time de cinco pessoas, copiar a Netflix é o caminho mais caro. Você herda a restrição do modelo (query-first, sem join) sem ter o time que opera anel, compactação e reparo. Cassandra brilha quando você já sabe a chave, a escrita dói mais que a consistência forte global, e cair um nó não pode cair o produto.

Instagram: PostgreSQL fatiado — e o que a Meta mudou depois

O Instagram ficou famoso por escalar com PostgreSQL + sharding, não por abandonar o relacional. Application servers em Django. Datastore principal em Postgres. Quando um servidor não aguentou mais, o time avaliou NoSQL e escreveu o contrário do slogan da época: o que melhor servia era continuar no PostgreSQL, espalhado em vários servidores.

A razão é o produto. Post, like, relacionamento, usuário: dados que se tocam. Você quer transação, índice, SQL, backup que um DBA entende, e a possibilidade de perguntar coisa nova sem criar uma tabela-cópia para cada query. Cassandra pede o oposto. O Instagram preferiu pagar o preço do sharding relacional.

O truque não foi “um Postgres enorme”. Foi separar shard lógico de máquina física. Cada shard lógico era um schema do Postgres. Havia milhares de schemas. Eles moravam em bem menos servidores. No começo, muitos schemas cabiam numa máquina. Quando aquela máquina doía, você movia um conjunto de schemas para outro Postgres — sem reescrever as chaves primárias, porque o ID já carregava o número do shard lógico.

Django
|
v
PostgreSQL (várias máquinas)
|
+-- schema insta1, insta2, ...  (shards lógicos)
|
mapeados em poucas máquinas físicas

ID de 64 bits gerado em PL/pgSQL:
41 bits  timestamp
13 bits  shard lógico
10 bits  sequência (% 1024)

Esse ID é o coração da solução. Num banco só, SERIAL resolve. Em vários bancos ao mesmo tempo, dois shards geram o mesmo 1 e o mundo quebra. O Instagram não pôs um gerador central (o Snowflake do Twitter era o outro caminho). Delegou a geração para o próprio Postgres, com função PL/pgSQL em cada schema. O ID sai único, ordenável por tempo, e o meio dele diz para qual máquina a aplicação deve ir. A aplicação não precisa de um catálogo extra para achar o post 123: ela abre o número e lê o shard.

              Instagram (arquitetura clássica)
                   |
         +---------+---------+
         v                   v
    Postgres #1         Postgres #2
    shards 1-500        shards 501-1000
         |                   |
         v                   v
    Postgres #3         Postgres #4

Eu já falei do Django nesse contexto em outro artigo. O ponto que a internet apaga é outro: existe diferença entre arquitetura clássica do Instagram e Instagram dentro da Meta em 2026.

A Meta opera um dos maiores deployments de MySQL do planeta: milhões de shards, petabytes, social graph, Messaging, Ads e Feed. Em 2023 o time descreveu o MySQL Raft exatamente nesse cenário — não como um blog de hobby, como operação de primário/réplica em escala em que failover feito por script Python já não era seguro o bastante. A solução foi meter consenso Raft dentro do próprio mysqld: promoção e membership deixam de ser orquestração externa e passam a ser log replicado. Por cima, o grafo social histórico não é SQL cru no app: é TAO, um cache/grafo que fala com MySQL por trás. Infra de sharding como o Shard Manager é compartilhada por Facebook, Messenger, WhatsApp e Instagram.

Traduzindo sem slogan: o Postgres é a história verdadeira do Instagram startup. O MySQL é o sistema nervoso da Meta, e o Instagram vive nesse organismo. Eu evitaria afirmar que “todo o Instagram de 2026 roda em PostgreSQL”. Também evitaria apagar o Postgres da biografia. Os dois fatos cabem na mesma frase. Quem escolhe só um está vendendo camiseta.

X / Twitter: Manhattan no núcleo, MySQL no relacional, Redis no quente

A desinformação aqui é industrial:

“Twitter usa Redis como banco principal.”

Não é bem assim. Redis é importantíssimo para timeline e dado quente. Não é a fonte persistente definitiva do tweet. Confundir cache com banco é o mesmo erro de achar que o CDN é o CMS.

A jornada de persistência do Twitter é uma aula de por que “qual banco” muda com o produto. No começo, monólito Rails (Monorail) e um MySQL com primário e réplica. Isso escala até o dia em que não escala. Vieram mais MySQLs, depois um período com Cassandra para ganhar horizontalidade, e em 2014 o time assumiu o próprio datastore: Manhattan.

Manhattan é um distributed key-value store multi-tenant. Não é SQL. Não é Redis. É um serviço com coordenador (roteia o request) e backend stateful (guarda o byte). Dado replica em um conjunto de instâncias — típico, três — chamado mirror-set. O próprio Twitter declarou que Manhattan virou o armazenamento padrão para persistência em tempo real e passou a guardar entidades centrais: tweets, users, direct messages. Por baixo, a partir de 2021, o storage engine de read/write pesado passou a ser RocksDB: LSM no SSD, menos espaço, escrita mais previsível do que o engine anterior para esse workload.

Por que não ficaram no Cassandra, se a Netflix ficou? Porque o Twitter queria um produto interno sob medida: multi-tenant de verdade, modelos de consistência que o time controla, operação em milhares de hosts, importação/exportação, e depois um caminho para trocar o motor de disco sem trocar a API que a aplicação vê. Cassandra resolve anel e CQL. Manhattan resolve “o tweet tem de estar aqui, com essa latência, nesse datacenter, com esse contrato”. São primos, não clones.

E o MySQL não foi para o museu. O post clássico MySQL at Twitter descreve uso pesado para dado relacional: usuário, autenticação, ads, commerce, trends, uma lista longa de serviços que se beneficiam de SQL. A representação honesta é duas persistências oficiais mais a camada quente:

Twitter / X

aplicação
    |
    +--> Manhattan  (tweets, users, DMs)
    |       |
    |     RocksDB no disco
    |
    +--> MySQL      (relacional: ads, auth, commerce...)
    |
    +--> Redis/cache (timeline, dado quente)
    |
    +--> search / analytics

Se a pergunta da entrevista for “qual banco o Twitter usa?”, a resposta que demonstra que você leu a fonte é: Manhattan para o núcleo em tempo real, MySQL para o relacional, Redis na camada quente. Quem responde só “Redis” está descrevendo o memcached da história antiga com o nome da moda.

Discord: o banco mudou porque a dor mudou

O Discord é o melhor antídoto contra a ideia de que a primeira escolha dura para sempre. Mensagens são append-mostly, chaveadas por canal, lidas do mais recente para trás, em volume de trilhões. Isso não é o modelo de um painel admin em Postgres. Também não é o modelo de um grafo social com join.

A história oficial tem três atos. Primeiro, MongoDB num replica set. Funcionou até o teto vertical aparecer. Em 2017 o time publicou a ida para Cassandra: escala horizontal, tolerância a falha, operação que um time pequeno ainda conseguia tocar. O cluster de mensagens cresceu até dezenas de nós, depois até quase duzentos. Aí a dor mudou de novo. Partição quente (um canal famoso, um evento ao vivo) concentrava leitura num pedaço do anel. GC da JVM pausava. Compactação atrasava. Latência p99 virava incêndio e o on-call virava fim de semana.

A resposta de 2023 não foi “vamos para SQL”. Foi trocar o motor mantendo o modelo: ScyllaDB, compatível com Cassandra, escrito em C++, shard por core, sem GC. O cluster de mensagens caiu de 177 nós para 72. Latência ficou previsível. Mas o time insiste num ponto que vale mais que o logo do banco: a camada acima do disco. Data services em Rust fazem coalescência — mil usuários pedindo a mesma mensagem viram uma ida só ao Scylla, e o resultado se espalha. Sem isso, o banco certo ainda derrete, porque o padrão de acesso é mil marteladas na mesma chave.

A lição não é “use ScyllaDB”. É: o Discord escolheu wide-column para mensagem porque a query é estreita e a escrita é enorme; trocou de motor quando o custo operacional do motor antigo passou do custo da migração; e tratou o serviço de acesso como parte da solução, não como detalhe de infra.

ChatGPT, Uber, Shopify, Meta: o relacional não morreu — ele ganhou um envelope

Enquanto Netflix e Discord empurram wide-column no caminho quente, outra família de gigantes continua em SQL. A diferença entre eles não é “Postgres versus MySQL” no sentido de sintaxe. É o envelope que puseram em volta do primário.

OpenAI / ChatGPT. PostgreSQL como sistema operacional de leitura massiva. Um primário de escrita, dezenas de réplicas globais, milhões de consultas por segundo. O produto é majoritariamente read. Transação e SQL ainda importam para estado de conta, sessão, configuração. Quando a escrita shardável ficou insuportável no primário, eles não shardaram o Postgres inteiro de primeira: migraram esses workloads para bancos distribuídos e deixaram o Postgres no núcleo que ainda se beneficia de um modelo de consistência simples. Eu destrinchei essa arquitetura em como a OpenAI escalou o PostgreSQL para o ChatGPT. A solução aqui não é um produto novo. É disciplina: não deixar join de doze tabelas no caminho quente, não deixar cache miss em massa acordar o primário, não deixar tabela nova nascer no único gargalo de write.

Uber. MySQL não aparece cru para o app de corrida. Aparece como Schemaless, depois como Docstore: banco distribuído, transacional, multi-modelo, com MySQL (InnoDB e, em parte, MyRocks) como motor de disco. A unidade de replicação é a transação MySQL. Consenso Raft espalha essa transação entre nós. O desenvolvedor interno ganha partição, visão materializada, CDC, sem ter de inventar shard id em PL/pgSQL. O time de storage cita dezenas de milhões de QPS e dezenas de petabytes. Cassandra existe na plataforma, para outros charters. O produto geral que a Uber oferece internamente para linha de negócio é o Docstore. A solução é exatamente o envelope: SQL/transacional embaixo, API distribuída em cima.

Shopify. Rails quer falar MySQL. O Shop app nasceu em KateSQL, o MySQL gerenciado internamente, numa instância só. Instância só tem teto. Em vez de reescrever o app em Cassandra, o time pôs Vitess na frente. Vitess nasceu no YouTube para o mesmo problema: MySQL que precisa virar muitos MySQLs sem o app perceber. A aplicação conecta no VTGate como se fosse um mysqld. O VTGate lê o VSchema, acha o shard pela chave (user_id no Shop app) e manda para o VTTablet ao lado de cada MySQL. Do ponto de vista do Rails, continua sendo SQL. Do ponto de vista da infra, são dezenas de primários. A migração foi faseada: primeiro “vitessificar” sem shard, depois dual-write de conexão, depois keyspace de usuário versus global, depois o split horizontal. Essa é a solução: não trocar o banco, trocar a topologia.

Shopify Shop app

Rails  ->  VTGate  ->  VTTablet + mysqld
                          |
                   shard por user_id

app continua falando SQL / protocolo MySQL
infra passa a ser N primários

Meta. MySQL em milhões de shards não é o MySQL do tutorial. É uma frota. TAO esconde o grafo. Shard Manager coloca pedaço em máquina. MySQL Raft tira o failover das mãos de um script frágil. O app do Feed não escolhe disco. Escolhe uma API de grafo. De novo: motor antigo, solução nova em volta.

Como escolher de verdade — sem copiar o logo

Se a pergunta real é “qual banco eu escolho para milhões de usuários”, a tabela de empresas é o pior atalho. Você não tem o Shard Manager da Meta, nem o Manhattan, nem o time de compactação da Netflix. Você tem um padrão de leitura e escrita, um time, e um orçamento de complexidade.

Comece por três perguntas, nesta ordem.

1. Eu já conheço a query quente, ou o produto ainda vai inventar pergunta? Se o dado tem relacionamento, invariante, relatório, ACL, billing, e você ainda não sabe todas as telas, a resposta honesta é PostgreSQL (ou MySQL, se o time já vive nisso). SQL é a ferramenta que deixa você errar o modelo no dia 1 e ainda assim consultar no dia 200. Cassandra e DynamoDB cobram o acerto no dia 1: a tabela é a query. Mudou a tela, mudou o schema, às vezes mudou a migração de petabyte.

2. A dor é leitura ou escrita? ChatGPT aguenta milhões de QPS em Postgres porque a carga é read e o primário foi protegido. Instagram shardou porque um Postgres não cabia o write e o dado. Netflix foi para Cassandra porque o write e a disponibilidade pesavam mais que o join. Discord foi para wide-column porque mensagem não pede join, pede append e leitura recente. Se o seu primário está morrendo de SELECT com join de doze tabelas, o banco novo não cura: a query cura. Se o primário está morrendo de INSERT, aí sim entra réplica (não resolve write), fila, ou fatiar.

3. Eu preciso de um anel, ou de um envelope em volta do SQL? Tem um meio-termo que a internet esquece. Você não precisa pular de Postgres para Cassandra no dia em que a instância dói. Instagram fatiou schema. Shopify pôs Vitess. Uber pôs Docstore. Citus existe. Particionamento nativo existe. Esse caminho dói, mas dói dentro de um modelo que o time já entende. Pular para wide-column cedo demais dói duas vezes: operação nova e modelo novo.

Redis entra depois. Cache, lock, rate limit, sessão quente, ranking. Quase nunca como fonte da verdade. O Twitter é o exemplo didático: Redis na timeline, Manhattan no tweet. Se o seu Redis é o único lugar onde o pedido da loja existe, você não tem cache. Tem um banco operacional disfarçado, com durabilidade de cache.

DynamoDB entra quando o modelo já é chave-acesso, você está na AWS, e não quer o time de Cassandra. A conta fecha se a partition key está certa e você não faz scan de tabela por hábito. A conta explode se você trata Dynamo como Postgres sem JOIN e sai criando GSI para cada tela nova.

Uma síntese útil, agora que o modelo de cada um já apareceu:

• PostgreSQL / MySQL: estado de produto, transação, query ainda viva. Escale leitura com réplica. Escale escrita com shard (schema, Vitess, Citus, Docstore) quando o primário gritar de verdade.
• Cassandra / ScyllaDB: chave conhecida, write-heavy, disponibilidade de anel. Modelar a query na tabela. Aceitar que analytics mora em outro lugar (Iceberg, warehouse).
• DynamoDB: o mesmo tipo de problema, sem cluster para operar, com a conta e o vendor lock da nuvem no lugar do on-call de nó.
• Manhattan e afins: você só constrói isso quando o produto é o datastore. Não copie o nome. Copie a lição: key-value interno existe porque o time precisou de contrato que o Cassandra da época não dava.
• Redis: camada quente. Não é o banco do Twitter, nem o seu, a menos que você tenha aceito perder o dado.

Para levar

Netflix → Cassandra, porque Member, Billing, Recommendations e Subscriptions pedem anel, não primário. Iceberg e S3 não desmentem isso: completam.

Instagram → PostgreSQL na história, com schema lógico e ID que carrega o shard. Hoje o produto vive no organismo MySQL da Meta. As duas frases são verdade.

Twitter / X → Manhattan / RocksDB + MySQL. Redis não é o banco. É o atalho da timeline.

Discord → ScyllaDB para mensagem, depois de Mongo e Cassandra. O data service em Rust é parte da solução.

ChatGPT → PostgreSQL protegido. Uber → Docstore em MySQL. Shopify → MySQL + Vitess. Meta → MySQL em escala, com TAO e Raft em volta.

A lição não é usar o que a Netflix usa. É perceber que cada um desses nomes escolheu o motor que casava com o padrão de acesso — e depois gastou anos construindo a solução em volta: abstração de key-value, shard lógico, Vitess, Docstore, Manhattan, data service. Quem copia só o logo copia o pedaço errado da história. Quem copia o padrão de acesso e o envelope é quem realmente leu o artigo de engenharia.

Referências

• Netflix Tech Blog — The Evolution of Cassandra Data Movement at Netflix (maio 2026)
• Instagram Engineering — Sharding & IDs at Instagram (espelho do post original)
• Engineering at Meta — Building and deploying MySQL Raft at Meta
• Engineering at Meta — Scaling services with Shard Manager
• X / Twitter Engineering — Adopting RocksDB within Manhattan
• X / Twitter Engineering — MySQL at Twitter
• Discord Engineering — How Discord Stores Trillions of Messages
• Uber Engineering — Evolving Schemaless into a Distributed SQL Database
• Uber Engineering — MySQL to MyRocks Migration in Uber’s Distributed Datastores
• Shopify Engineering — Horizontally scaling the Rails backend of Shop app with Vitess