Foco: você entende quando cliente diz "passamos pra MongoDB porque era mais escalável" e avalia se a escolha foi acertada ou modinha. NoSQL é poderoso mas mal aplicado custa caro.

Pré-requisito: Semana 1 (SQL fundamentals). Tempo estimado: 3-4 horas de leitura + 1 hora de exercício. Output prático: você opina com substância quando cliente discute SQL vs NoSQL, sem cair nem em "SQL é antiquado" nem em "NoSQL é moda".

Por que essa semana importa

NoSQL teve seu boom em 2010-2015. Marketing forte, casos de uso reais limitados, MUITA gente migrou achando que ia escalar mais. Resultado: hoje 30-50% das empresas que adotaram MongoDB/Cassandra estão arrependidas e migrando de volta pra Postgres.

Mas NoSQL tem casos onde É a escolha certa. Saber distinguir os dois cenários é vocabulário técnico de quem realmente entende. Cliente que escolheu NoSQL bem fica feliz com você quando você reconhece a escolha. Cliente que escolheu mal fica em dívida com você quando você aponta isso direto.

Bônus: várias features de Team Studio podem usar NoSQL ESPECÍFICO (Redis pra cache de contexto, vector DB pra embeddings). Saber escolher onde aplicar é vantagem.

1. O modelo mental: por que NoSQL apareceu

Bancos relacionais (SQL) dominaram a indústria de 1970 até 2010. Funcionaram bem porque: - Garantem consistência (ACID) - Têm linguagem padrão (SQL) - Estruturam dados de forma intuitiva (tabelas + relacionamentos)

Mas chegando 2005-2010, empresas tipo Google, Amazon, Facebook ATINGIRAM LIMITES: - Bilhões de registros (banco relacional vertical não aguenta) - Tráfego global distribuído (latência da única instância matava) - Schema flexível (cada usuário com campos diferentes) - Picos massivos (Black Friday vezes 10)

Soluções existentes (escalar Postgres horizontalmente, sharding manual) eram MUITO trabalhosas. Empresas começaram a construir bancos com filosofia diferente:

  • Google → BigTable (2006) → Cassandra (Facebook, open source)
  • Amazon → Dynamo paper (2007) → DynamoDB (produto)
  • 10gen → MongoDB (2009) - popularizou o termo NoSQL
  • Salvatore Sanfilippo → Redis (2009) - cache mas vira banco

Por volta de 2012, "NoSQL" virou buzzword. Muita empresa que NÃO era Google migrou pra MongoDB achando que ia ganhar escala. Maioria descobriu que tinha trocado problemas conhecidos por problemas novos.

A lição: NoSQL não é "SQL melhor". É "SQL com trade-offs diferentes". Escolher errado custa caro.

2. As 4 famílias NoSQL

NoSQL é guarda-chuva pra coisas BEM diferentes. Quatro famílias principais, cada uma com casos de uso próprios:

2.1 Document store - JSON estruturado

Como armazena: documentos JSON (ou similar). Cada documento é flexível, pode ter campos diferentes.

Exemplo (MongoDB):

{
  "_id": "u123",
  "nome": "Ana",
  "email": "ana@email.com",
  "tags": ["vip", "early-adopter"],
  "endereco": { "cidade": "SP", "cep": "01000-000" }
}

Casos de uso bons: - Catálogos de produtos (cada produto tem atributos diferentes) - Conteúdo (artigos, posts, formulários flexíveis) - Perfis de usuário com schema variável - Eventos analíticos heterogêneos

Ferramentas dominantes: - MongoDB (mais popular) - CouchDB (clássico, foco em sincronização) - Firestore (Google, integrado com Firebase) - DocumentDB (AWS, compatível com MongoDB)

Quando NÃO usar: - Dados altamente relacionais (3+ joins por query): SQL é melhor - Necessita transações multi-documento ACID rígido: MongoDB suporta desde 2018 mas é mais complexo que em SQL

2.2 Key-value store - chave → valor simples

Como armazena: estrutura "dicionário" gigante. Chave única → valor (qualquer coisa).

Exemplo (Redis):

SET user:123 "ana@email.com"
GET user:123  → "ana@email.com"

SET session:abc123 "{user_id: 'u123', expires: '2026-12-31'}"
SET cache:dashboard:u123 "<dados pesados pre-calculados>" EX 300

Casos de uso bons: - Cache (Redis é REI disso) - Sessões de usuário - Rate limiting - Leaderboards (sorted sets) - Pub/sub leve - Locks distribuídos

Ferramentas dominantes: - Redis (mais popular, in-memory) - Memcached (cache puro, sem persistência) - DynamoDB (AWS, key-value persistente) - Etcd (configuração distribuída, Kubernetes usa)

Quando NÃO usar: - Query complexa: você só consegue acessar por chave - Relacionamentos: não tem joins - Análise: não tem agregação

2.3 Wide-column store - tabela gigante esparsa

Como armazena: tabela tipo SQL mas com colunas dinâmicas e schema flexível. Cada linha pode ter colunas diferentes.

Exemplo (Cassandra):

CREATE TABLE eventos (
  user_id UUID,
  timestamp TIMESTAMP,
  evento TEXT,
  PRIMARY KEY ((user_id), timestamp)
);

Particionado por user_id, ordenado por timestamp. Permite escrever bilhões de linhas e ler por user em milissegundos.

Casos de uso bons: - Time-series (eventos, logs, métricas) - IoT (sensores enviando dados) - Analytics em escala (Facebook usa Cassandra pra mensagens) - Sistemas distribuídos globalmente

Ferramentas dominantes: - Cassandra (Apache, popular) - ScyllaDB (Cassandra-compatível mas mais rápido) - BigTable (Google) - HBase (Apache, sobre Hadoop)

Quando NÃO usar: - Você precisa de queries flexíveis (Cassandra exige modelar tabela por query) - Volume baixo: complexidade não compensa - Não tem time pra operar Cassandra (não é trivial)

2.4 Graph database - nós e arestas

Como armazena: dados como GRAFO. Nós (entidades) conectados por arestas (relacionamentos).

Exemplo (Neo4j):

(:Pessoa {nome: 'Ana'})-[:CONHECE]->(:Pessoa {nome: 'Bruno'})
(:Pessoa {nome: 'Bruno'})-[:TRABALHA_EM]->(:Empresa {nome: 'Globo'})

Pra perguntar "quem Bruno conhece que trabalha em empresa de Ana?":

MATCH (ana:Pessoa {nome:'Ana'})-[:TRABALHA_EM]->(empresa)
MATCH (bruno:Pessoa {nome:'Bruno'})-[:CONHECE]->(amigo)
MATCH (amigo)-[:TRABALHA_EM]->(empresa)
RETURN amigo

Casos de uso bons: - Rede social (relacionamentos como FB, LinkedIn) - Recomendação ("pessoas que compraram X também compraram Y") - Detecção de fraude (rastreio de transações suspeitas) - Knowledge graphs (Wikipedia, IBM Watson) - Gerenciamento de identidade e acessos (IAM)

Ferramentas dominantes: - Neo4j (mais popular, open core) - Amazon Neptune - TigerGraph - ArangoDB (multi-modelo: documento + grafo)

Quando NÃO usar: - Dados naturalmente tabulares: SQL é mais simples - Volume muito grande: alguns grafos não escalam tão bem - Time sem expertise (Cypher é diferente de SQL)

2.5 Multi-model - versáteis

Algumas plataformas modernas suportam VÁRIAS famílias ao mesmo tempo:

  • PostgreSQL (relacional mas com JSONB, hstore, pgvector, pg_trgm) - virou "Swiss army knife"
  • MongoDB (documento + Atlas Search + Time Series)
  • ArangoDB (documento + grafo + key-value)
  • Cosmos DB (Azure: multi-model)

Postgres em particular ganhou tantos plugins que hoje você consegue resolver 90% dos casos de uso sem precisar de banco separado. Isso vem revertendo a onda NoSQL.

3. CAP theorem - a regra que governa bancos distribuídos

CAP theorem (Eric Brewer, 2000) diz: em sistema distribuído, você pode garantir DUAS de três propriedades:

  • C Consistency: toda leitura retorna o dado mais recente OU erro
  • A Availability: toda request recebe resposta (não necessariamente a mais recente)
  • P Partition tolerance: sistema continua operando se rede particionar

Como rede particionar é INEVITÁVEL em sistemas distribuídos reais, você na prática escolhe entre:

  • CP (Consistency + Partition tolerance): sacrifica disponibilidade durante partição
  • AP (Availability + Partition tolerance): sacrifica consistência (eventual)

3.1 CP em prática

Quando rede particionar, sistema FALA "não posso responder com certeza, melhor não responder".

Bancos CP: MongoDB (replica set, leitura no primário), HBase, Zookeeper, etcd.

Quando usar: financeiro, inventário, autenticação. Dado errado é PIOR que sistema indisponível.

3.2 AP em prática

Quando rede particionar, sistema responde com o que tem (pode ser desatualizado). Reconcilia depois.

Bancos AP: Cassandra, DynamoDB, CouchDB, Riak, Redis (replicação assíncrona).

Quando usar: timeline social, contagem de likes, eventos analíticos. Resposta imediata mais importante que perfeita consistência.

3.3 Eventual consistency - o filho do AP

Sistema AP eventualmente fica consistente (segundos a minutos). Importante entender:

  • "Eventual" não é "nunca": geralmente 100ms a 5s
  • Pode ter inconsistência temporária (você lê dado antigo enquanto réplica não atualizou)
  • Aplicação precisa lidar com isso (idempotência, retry, conflict resolution)

3.4 Strong consistency vs eventual consistency em SQL/NoSQL

Estereótipo é "SQL = consistente, NoSQL = eventual". Mas REALIDADE é mais nuançada:

  • Postgres por padrão: strong consistency
  • Postgres com read replicas: eventual em leituras de réplica
  • MongoDB single node: strong consistency
  • MongoDB sharded com majority writes: configurável
  • Cassandra: eventual por padrão, mas tem QUORUM consistency

A escolha de consistência é configuração, não característica fixa do banco.

3.5 PACELC - extensão moderna do CAP

CAP só fala de partições. PACELC adiciona: e em operação NORMAL, você troca latência por consistência?

  • PA-EL (Cassandra padrão): durante partição, prefere availability. Em operação normal, prefere baixa latência (eventual).
  • PC-EC (Postgres síncrono): durante partição, prefere consistência. Em operação normal, prefere consistência.
  • PA-EC: raro mas existe (MongoDB com write concerns específicos).

Você não precisa decorar PACELC. Reconhecer que existe vai te dar respeito em conversa de arquiteto distribuído.

4. ACID vs BASE - filosofias opostas

4.1 ACID (bancos relacionais clássicos)

  • Atomicity: transação é tudo ou nada
  • Consistency: dado sempre em estado válido (constraints, foreign keys)
  • Isolation: transações paralelas não interferem
  • Durability: dado comitado é persistido

Vantagem: garantias fortes, mais fácil raciocinar. Custo: performance limitada em escala global.

4.2 BASE (bancos NoSQL distribuídos)

  • Basically Available: sistema responde, mesmo que com dado parcial
  • Soft state: estado pode mudar com tempo (mesmo sem input)
  • Eventual consistency: vai ficar consistente em algum momento

Vantagem: escala globalmente, performance massiva. Custo: lógica de aplicação precisa lidar com inconsistência.

4.3 Quando escolher

ACID: pagamentos, contabilidade, inventário, autenticação. Qualquer coisa onde "estar errado por 5 segundos" é problema sério.

BASE: posts sociais, contadores, analytics, recomendações. Qualquer coisa onde performance e disponibilidade pesam mais que precisão imediata.

Frequentemente UMA aplicação usa AMBOS: - Pedido finaliza em Postgres (ACID, dado financeiro) - Histórico de browsing vai em Cassandra (BASE, alto volume) - Sessão fica em Redis (BASE, performance) - Recomendação vai em Neo4j (BASE, relacionamentos)

5. Quando NoSQL é solução vs quando é moda

5.1 Casos onde NoSQL VENCE genuinamente

  1. Cache → Redis sempre vence Postgres
  2. Time-series com volume gigante (IoT, logs, métricas) → Cassandra ou TimescaleDB (Postgres extension)
  3. Sessões de usuário → Redis ou DynamoDB
  4. Catálogo com schema variável → MongoDB pode fazer sentido (mas Postgres com JSONB também)
  5. Rede de relacionamentos → Neo4j (Postgres não consegue)
  6. Scale GLOBAL real (milhões de QPS) → Cassandra, DynamoDB
  7. Embeddings/vetores semânticos → Pinecone, Weaviate, pgvector (Postgres extension)

5.2 Casos onde NoSQL foi MODA (não funcionou bem)

  1. CRM/ERP/sistema interno tradicional: dados relacionais, Postgres resolve melhor
  2. Startup pré-Product Market Fit: complexidade não compensa o pequeno volume
  3. "Achamos que vamos escalar pra 1 bilhão de usuários" mas tem 1000: prematuro
  4. Time sem expertise NoSQL específico: vai sofrer mais que ganhar
  5. Necessidade de queries flexíveis e analytics: SQL inata mais natural

5.3 A onda de "back to Postgres"

Desde ~2020, várias empresas migraram DE VOLTA pra Postgres:

  • Basecamp: relatou que migrar de MongoDB pra Postgres reduziu complexidade
  • Stripe continua em Postgres apesar do volume
  • Uber publicamente reverteu de Postgres pra MySQL (raro mas existe)
  • Notion migrou de MongoDB pra Postgres com sucesso

Razão: Postgres EVOLUIU MUITO. Hoje suporta JSONB (documento), pgvector (embeddings), Postgis (geo), pg_trgm (full-text), pg_partman (particionamento). Vira "Swiss army knife" suficiente pra 80% dos casos.

Pergunta de reunião:

"Por que vocês escolheram NoSQL X em vez de Postgres? Foi necessidade real ou hype da época?"

Resposta honesta diferencia cliente maduro de cliente que comprou trend.

6. Cinco perguntas que destravam reunião sobre NoSQL

6.1 "Qual problema vocês estavam resolvendo quando escolheram esse NoSQL?"

Por que importa: revela se foi decisão fundamentada ou hype. Cliente articulado tem resposta clara.

6.2 "Volume de dados e operações por segundo? Quantos nós no cluster?"

Por que importa: NoSQL distribuído faz sentido em ESCALA. Cluster de 3 nós pra 10k registros é over-engineering.

6.3 "Como vocês modelaram os dados? Têm joins frequentes?"

Por que importa: muitos joins em document store = sinal de modelagem errada. NoSQL exige modelar pela QUERY que você vai fazer.

6.4 "Como vocês fazem queries analíticas? Têm pipeline pra ETL pra warehouse?"

Por que importa: NoSQL operacional + warehouse analítico é padrão. Empresa que faz analytics direto no MongoDB sofre.

6.5 "Qual o nível de consistência configurado? Strong, bounded staleness ou eventual?"

Por que importa: revela maturidade. Cliente que não sabe responder não controla o trade-off CAP que ele tem.

7. Exercício prático

Cenário: cliente potencial Team Studio. Startup com 18 meses, captou R$ 5M de seed. Time tech tem 8 devs.

"Nosso CTO veio do Google e adora arquitetura distribuída. Quando começamos, ele escolheu MongoDB pra tudo + Cassandra pra eventos + Redis pra cache + Neo4j pra recomendação. Temos 30k usuários ativos. Os custos de infra estão em US$ 25k/mês e ninguém consegue rodar o sistema local. Conseguem ajudar?"

Pratique: 1. Identifique 3 sinais de over-engineering nesse cenário 2. Faça 5 perguntas pra confirmar diagnóstico antes de propor solução 3. Esboce uma proposta de simplificação (qual NoSQL fica, qual sai) 4. Identifique 1 oportunidade pra Team Studio dentro disso

(Sugestões no fim.)

8. Material extra

Leitura essencial: - "Designing Data-Intensive Applications" (Martin Kleppmann), capítulos 2-3 (modelos de dados, armazenamento) - "NoSQL Distilled" (Pramod Sadalage & Martin Fowler) - livro curto, leitura em 3 horas - Blog "Use the Index, Luke" (https://use-the-index-luke.com/) - focado em SQL mas mostra POR QUE SQL é poderoso

Vídeos: - "Mongo DB is web scale" (paródia famosa, 4 min) - leitura recreativa - "How Postgres replaces MongoDB" - busca no YouTube

Hands-on (2 horas): - Instale Postgres + MongoDB localmente (Docker compose) - Modele a mesma estrutura nos dois (clientes + pedidos + produtos) - Faça queries equivalentes - Sinta a diferença

9. Sugestões pro exercício prático (veja só depois de tentar)

3 sinais de over-engineering:

  1. 4 bancos NoSQL diferentes pra 30k usuários ativos: cada um adiciona complexidade operacional. Empresa madura com 30M usuários geralmente tem 2-3 bancos. Startup com 30k devia ter 1.
  2. "Ninguém consegue rodar o sistema local": sinal claro de complexidade que não escala pra time. Onboarding novo dev leva semanas. Time perde tempo gerencial.
  3. US$ 25k/mês de infra pra 30k usuários: ~US$ 0.83/usuário/mês só de infra. Em SaaS B2C, isso é absurdamente alto. Sugere recursos overprovisionados ou má arquitetura.

5 perguntas pra confirmar:

  1. "Quais queries reais cada banco serve? Quantas QPS em cada um?"
  2. "Vocês têm dados duplicados entre MongoDB e Cassandra? Mantêm sync manualmente?"
  3. "Quando dá problema em produção, em qual banco é mais difícil debugar?"
  4. "Quantas horas/semana o time gasta operando esses bancos vs construindo produto?"
  5. "Se tivessem que cortar custo pela metade rápido, qual desses bancos eliminariam primeiro?"

Esboço de simplificação:

  • Manter Postgres (substitui MongoDB pra catálogo, JSONB resolve schema flexível; substitui Neo4j pra recomendação simples)
  • Manter Redis (cache é insubstituível por enquanto)
  • Eliminar Cassandra (30k usuários não precisa, eventos podem ir pro Postgres ou um data warehouse barato)
  • Eliminar Neo4j (recomendação simples roda em Postgres com extensão de grafo OU em SQL puro pra escala atual)

Custo estimado pós-simplificação: US$ 25k → US$ 6-8k/mês. Mais simples de operar, mais rápido pra contratar.

Oportunidade pra Team Studio:

Agente "advisor de arquitetura": roda 1x por mês sobre métricas de uso dos bancos, identifica overprovisionamento, sugere otimizações com base em padrões reais. Não substitui CTO, complementa. Setup: 2 semanas. Valor: pode pagar Team Studio sozinho em economias de infra.

10. Próxima semana

Esta semana fecha o Bloco A (Dados) junto com a Semana 1 (SQL) e Semana 3 (ETL/ELT). A trilha continua no Bloco B (Cloud e Infra) com modelos cloud, autoscaling e SLA dos provedores.

A trilha completa: 16 semanas em 6 blocos cobrindo dados, cloud, devops, APIs, segurança e arquitetura.