1.1 O documento: a unidade de tudo

Um documento é um objeto tipo JSON: pares campo-valor, onde o valor pode ser um escalar, um array ou outro objeto aninhado. A coleção agrupa documentos; o database agrupa coleções. Não há esquema declarado — dois documentos da mesma coleção podem ter campos diferentes (o que é liberdade e perigo em doses iguais).

// Um documento de pedido — o que em SQL seriam 3-4 tabelas com JOIN
{
  "_id": ObjectId("665f1b2c9d3e4a0012ab34cd"),
  "numero": 10432,
  "cliente": { "id": "u1", "nome": "Ana Souza" },
  "itens": [
    { "sku": "CAM-01", "qtd": 2, "preco": 79.90 },
    { "sku": "MEIA-03", "qtd": 1, "preco": 19.90 }
  ],
  "status": "pago",
  "criadoEm": ISODate("2026-06-04T13:20:00Z")
}

1.2 BSON: o que o MongoDB realmente grava

Você escreve JSON, mas o MongoDB armazena e trafega BSON (Binary JSON): um formato binário que adiciona tipos que JSON não tem e torna a varredura eficiente (cada campo é prefixado por tipo e tamanho).

• Tipos que só existem em BSON: ObjectId (12 bytes: timestamp + contador + aleatório — ordenável por criação), Date (inteiro de 64 bits, ms desde epoch), Decimal128 (decimal exato — use para dinheiro, nunca double), Binary, Int32/Int64, Timestamp interno.
• Limite rígido: um documento tem no máximo 16 MB. Não é sugestão — é o teto que molda toda a modelagem (módulo 2).
• Profundidade máxima: 100 níveis de aninhamento.

1.3 CRUD com tradução SQL

// Operadores de consulta que você usa todo dia
db.pedidos.find({ valor: { $gte: 100, $lt: 500 } })          // faixa
db.pedidos.find({ status: { $in: ["pago", "enviado"] } })       // lista
db.pedidos.find({ "cliente.nome": "Ana Souza" })              // campo aninhado por dot notation
db.pedidos.find({ itens: { $elemMatch: { sku: "CAM-01", qtd: { $gt: 1 } } } })  // array de objetos
db.pedidos.find({ cupom: { $exists: false } })                // campo ausente

// Operadores de update
{ $set: {...} }  { $inc: { estoque: -1 } }  { $push: { itens: {...} } }
{ $pull: { tags: "promo" } }  { $addToSet: { tags: "vip" } }  { $unset: { cupom: "" } }

1.4 O driver e o pool de conexões o que produção cobra

No shell tudo parece mágico. Na aplicação, você usa um driver (Node, Python/PyMongo, Java, Go...) e ele mantém um pool de conexões — um conjunto de sockets reutilizados. Erros clássicos:

// Node — UMA instância de MongoClient para todo o processo, criada no boot
const client = new MongoClient(uri, {
  maxPoolSize: 20,          // teto de conexões simultâneas por instância da app
  minPoolSize: 2,
  serverSelectionTimeoutMS: 5000,
  retryWrites: true    // reexecuta escrita idempotente uma vez em falha de rede transitória
});
await client.connect();   // no startup, não a cada request
export const db = client.db("loja");

2.1 A pergunta central

No relacional você normaliza por reflexo. No MongoDB, a pergunta é: estes dois dados são lidos juntos quase sempre? Se sim, aninhe (embedding) — uma leitura resolve. Se não, ou se o lado "muitos" cresce sem limite, referencie (guardar o _id do outro, como uma FK que você resolve na aplicação ou com $lookup).

// EMBEDDING — endereços vivem dentro do usuário
{ _id: "u1", nome: "Ana", enderecos: [ { rotulo: "casa", cidade: "Recife" } ] }

// REFERENCING — pedidos apontam para o usuário
{ _id: "p1", clienteId: "u1", valor: NumberDecimal("250.00") }

2.2 A regra da cardinalidade

2.3 Os três antipadrões que explodem em produção

2.4 Extended Reference: o meio-termo que o mercado usa

Referenciar puro obriga a um segundo fetch para exibir "o nome do cliente no pedido". Extended Reference duplica 2–3 campos estáveis do documento referenciado:

{ _id: "p1", clienteId: "u1",
  cliente: { nome: "Ana Souza", cidade: "Recife" },   // cópia para exibição rápida
  itens: [ { sku: "CAM-01", nome: "Camiseta Preta", preco: NumberDecimal("79.90"), qtd: 2 } ] }

O nome do produto e o preço dentro do item do pedido são dado histórico congelado: se o produto mudar de nome ou preço amanhã, o pedido de ontem não deve mudar. Aqui a duplicação não é um mal necessário — é a modelagem correta.

3.1 O modelo mental: uma esteira de estágios

O aggregate() recebe um array de estágios. Cada estágio recebe o fluxo de documentos do anterior, transforma e passa adiante — como | no shell Unix. É GROUP BY + subqueries + JOIN + window functions, tudo encadeável.

db.pedidos.aggregate([
  { $match:   { criadoEm: { $gte: ISODate("2026-01-01") }, status: "pago" } },  // WHERE — o mais cedo possível
  { $unwind:  "$itens" },                                                // explode o array em 1 doc por item
  { $group:   { _id: "$itens.sku",
               receita: { $sum: { $multiply: ["$itens.preco", "$itens.qtd"] } },
               unidades: { $sum: "$itens.qtd" } } },
  { $sort:    { receita: -1 } },
  { $limit:   10 },
  { $project: { sku: "$_id", receita: 1, unidades: 1, _id: 0 } }
])

3.2 Os estágios que você vai usar

3.3 $lookup: o JOIN que você deve evitar (mas às vezes precisa)

{ $lookup: {
    from: "clientes",
    localField: "clienteId",
    foreignField: "_id",
    as: "cliente"          // vira um ARRAY (mesmo que 0 ou 1) — some com $unwind depois
} }

Funciona, mas cada documento do fluxo dispara uma busca na coleção externa. Em escala, é o gargalo. As saídas de mercado: Extended Reference (módulo 2 — você já tem o nome do cliente no pedido, não precisa do $lookup), ou aceitar o $lookup só em telas de baixo volume (admin, relatório) com índice em clientes._id (que já existe) e no localField.

3.4 $facet: a tela de listagem com filtros numa request

db.produtos.aggregate([
  { $match: { categoria: "calcados" } },
  { $facet: {
      pagina:        [ { $sort: { vendas: -1 } }, { $skip: 0 }, { $limit: 20 } ],
      total:         [ { $count: "n" } ],
      porMarca:      [ { $group: { _id: "$marca", n: { $sum: 1 } } }, { $sort: { n: -1 } } ],
      faixaDePreco:  [ { $bucket: { groupBy: "$preco", boundaries: [0, 100, 300, 1000],
                        default: "1000+", output: { n: { $sum: 1 } } } } ]
  } }
])

Um único aggregate devolve os itens da página, a contagem para a paginação e as facetas da barra lateral — o que seriam 3–4 idas ao banco.

3.5 Materializar: rollups com $merge avançado

Dashboards que recalculam "vendas por dia dos últimos 2 anos" a cada carregamento são caros. Rode a agregação uma vez por hora (job agendado ou Atlas Trigger) e grave numa coleção vendas_diarias com $merge — as telas leem dela instantaneamente. É o padrão Computed/CQRS aplicado dentro do próprio MongoDB.

4.1 Os tipos de índice

db.clientes.createIndex({ email: 1 }, { unique: true })            // único
db.pedidos.createIndex({ clienteId: 1, criadoEm: -1 })                // composto (ordem importa!)
db.produtos.createIndex({ nome: "text", descricao: "text" })          // texto (básico)
db.lojas.createIndex({ local: "2dsphere" })                          // geoespacial
db.eventos.createIndex({ expiraEm: 1 }, { expireAfterSeconds: 0 })    // TTL — apaga sozinho
db.pedidos.createIndex({ status: 1 }, { partialFilterExpression: { status: "aberto" } })  // parcial: só indexa o que importa
db.usuarios.createIndex({ cpf: 1 }, { unique: true, sparse: true })     // esparso: ignora docs sem o campo

• Multikey: indexar um campo que é array cria automaticamente um índice multikey (uma entrada por elemento). Um índice composto pode ter no máximo um campo array.
• Parcial > esparso: partialFilterExpression é mais expressivo e é o recomendado hoje.

4.2 A regra ESR para índices compostos

Por quê: igualdade fixa um ponto de entrada estreito no índice; a ordenação sai "de graça" se vier logo depois (sem etapa de sort em memória); a faixa varre um trecho e é a última a "abrir o leque".

4.3 Lendo o explain("executionStats")

db.pedidos.find({ clienteId: "u1" }).sort({ criadoEm: -1 }).explain("executionStats")

Covered query: se todos os campos da projeção (e do filtro) estão no índice, o plano mostra PROJECTION_COVERED e o FETCH some — o MongoDB nem toca nos documentos. É a consulta mais rápida possível.

4.4 O custo do índice e o working set

• Cada índice ocupa RAM e torna toda escrita mais lenta (o índice também é atualizado). Indexe consultas reais e frequentes.
• Working set = dados + índices efetivamente acessados. Se ele não cabe na RAM do servidor, o MongoDB pagina do disco e a latência despenca. Dimensione a máquina pelo working set, não pelo dataset total.
• Encontre índices inúteis com $indexStats (db.col.aggregate([{ $indexStats: {} }])) — se accesses.ops é ~0 há semanas, remova.
• $regex sem âncora (/ana/) não usa índice; /^ana/ (prefixo) usa. Busca textual de verdade → índice text ou Atlas Search (módulo 8).

5.1 O catálogo de padrões (os que caem em entrevista)

5.2 Bucket pattern na prática (séries temporais "na mão")

// Em vez de 1 documento por leitura (milhões/dia), 1 documento por sensor por hora
{
  sensorId: "s-42",
  hora: ISODate("2026-06-04T13:00:00Z"),
  n: 60,
  leituras: [ { t: 0, v: 21.4 }, { t: 60, v: 21.5 }, /* ... */ ],
  min: 21.1, max: 22.0, soma: 1284.6           // agregados do bucket (padrão Computed embutido)
}

Escrita: updateOne({ sensorId, hora }, { $push: { leituras: {...} }, $inc: { n: 1, soma: v }, $min: { min: v }, $max: { max: v } }, { upsert: true }). Leituras de dashboard varrem dezenas de buckets em vez de milhões de documentos. (Desde a versão 5.0 há Time Series Collections nativas — módulo 9 — que fazem isso por baixo dos panos; o bucket manual ainda importa para entender e para casos fora do modelo nativo.)

5.3 Migrações sem downtime

1. Código tolerante primeiro: faça a aplicação ler tanto o formato antigo quanto o novo (ex.: const nome = doc.nomeCompleto ?? \`${doc.nome} ${doc.sobrenome}\`). Só depois toque nos dados.
2. Migração preguiçosa: ao gravar um documento antigo, converta-o e marque schemaVersion: 2. Barato, gradual, mas nunca termina sozinho para dados frios.
3. Backfill em lotes: job que percorre { schemaVersion: { $lt: 2 } } em páginas de alguns milhares, com updateMany ou pipeline de update, pausas entre lotes para não saturar I/O, e retomável (guarda o último _id).
4. Validação JSON Schema: depois do backfill, ligue db.runCommand({ collMod: "col", validator: {...}, validationLevel: "moderate" }) para impedir regressão ao formato antigo.

6.1 O Replica Set

Um replica set é um grupo de nós com uma cópia dos mesmos dados: 1 primário (aceita escritas) + N secundários que replicam o oplog (um log com cada operação, em coleção limitada). Se o primário some, os nós restantes fazem uma eleição (protocolo tipo Raft) e promovem um secundário em segundos. É o mínimo para produção — nunca rode um nó só.

• Oplog: idempotente por design (reaplicar não estraga). Seu tamanho define a janela de recuperação: um secundário que ficou fora tempo demais para "cair do oplog" precisa de ressincronização completa.
• Árbitro: nó sem dados que só vota, para desempatar em setups de 2 nós. Evite se puder — 3 nós com dados é melhor (um árbitro não dá durabilidade a w:"majority").
• Lag de replicação: quanto os secundários estão atrás do primário. Métrica crítica; se cresce, leituras em secundário servem dados velhos e w:"majority" fica lento.

6.2 Write Concern — quão durável é "gravado"

6.3 Read Concern e Read Preference

• readConcern — qual "versão" você lê: "local" (o que este nó tem agora), "majority" (só o que a maioria confirmou — não sofre rollback), "linearizable" (a mais recente confirmada, com custo), "snapshot" (usado em transações).
• readPreference — de qual nó você lê: primary (consistente, padrão), primaryPreferred, secondary, secondaryPreferred (escala leitura aceitando lag), nearest (menor latência de rede).

6.4 Transações multi-documento

Operações num único documento são atômicas por natureza — e boa modelagem (embedding do que muda junto) resolve a maioria dos casos sem transação. Desde a 4.0 (replica set) / 4.2 (sharded) existem transações ACID multi-documento:

const session = client.startSession();
try {
  await session.withTransaction(async () => {
    await contas.updateOne({ _id: "A" }, { $inc: { saldo: -100 } }, { session });
    await contas.updateOne({ _id: "B" }, { $inc: { saldo:  100 } }, { session });
  }, { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } });
} finally { await session.endSession(); }

7.1 Anatomia de um cluster shardado

• mongos — roteador sem estado; a aplicação fala com ele. Decide qual shard tem o dado a partir da shard key.
• Config servers (um replica set) — guardam o mapa de quais faixas de shard key vivem em qual shard.
• Shards — cada um é um replica set completo, dono de uma fatia dos dados.
• Chunk — faixa contígua de valores da shard key; o balancer move chunks entre shards para equilibrar.

7.2 Escolhendo a shard key

Uma boa shard key tem três propriedades ao mesmo tempo:

1. Alta cardinalidade — muitos valores distintos (senão os chunks não se dividem).
2. Baixa frequência / distribuição uniforme — nenhum valor concentra a maioria dos documentos (senão jumbo chunk).
3. Presente nas consultas mais comuns — senão toda consulta vira scatter-gather (pergunta a todos os shards e junta).

7.3 Padrões de sharding

• Hashed sharding — sh.shardCollection("db.col", { userId: "hashed" }). Espalha escritas; perde localidade de faixa.
• Ranged sharding — mantém localidade (consultas por faixa tocam poucos shards); exige shard key não-monotônica.
• Compound shard key — o mais usado em produção: um prefixo de igualdade (tenant, região) + um sufixo de alta cardinalidade.
• Zone sharding — amarrar faixas de shard key a shards físicos (ex.: dados de clientes da UE em shards na Europa) para compliance/latência.

8.1 Atlas Search — Lucene dentro do MongoDB

O índice text nativo é fraco (sem relevância boa, sem análise linguística, sem faceta rica). Atlas Search embute o Apache Lucene (o motor do Elasticsearch) no cluster: um índice de busca sincronizado automaticamente com as coleções, consultado pelo estágio $search no aggregation pipeline.

db.produtos.aggregate([
  { $search: {
      index: "produtos",
      compound: {
        must:   [ { text: { query: "tênis corrida", path: ["nome", "descricao"], fuzzy: { maxEdits: 1 } } } ],
        filter: [ { range: { path: "preco", lte: 500 } } ]
      }
  } },
  { $project: { nome: 1, preco: 1, score: { $meta: "searchScore" } } }
])

Para muitos casos, isso elimina a necessidade de manter um Elasticsearch separado e todo o pipeline de CDC para sincronizá-lo (o problema do módulo 9 da apostila de NoSQL). Facetas, autocomplete, sinônimos, highlighting — tudo dentro do mesmo banco.

8.2 Atlas Vector Search — a base de RAG tema em alta

Guarde o embedding (vetor de floats) de cada documento num campo e crie um índice vetorial. O estágio $vectorSearch faz busca por similaridade (kNN aproximado, HNSW):

{ $vectorSearch: {
    index: "docs_vec",
    path: "embedding",
    queryVector: [ 0.012, -0.043, /* ...1536 dims... */ ],
    numCandidates: 200,
    limit: 5,
    filter: { tenantId: "t1" }        // pré-filtro combinado com a busca vetorial
} }

Combinado com $search textual na mesma query, você tem busca híbrida (semântica + palavra-chave) sem um banco vetorial dedicado. Conecta diretamente com a apostila de IA Generativa & RAG.

8.3 O resto do ecossistema Atlas

9.1 Performance tuning sob carga

• Perfil de consultas lentas: o database profiler (db.setProfilingLevel(1, { slowms: 100 })) grava em system.profile toda operação acima do limite. Em Atlas, o Performance Advisor sugere índices a partir disso.
• WiredTiger cache: por padrão ~50% da RAM. Métrica-chave: cache hit ratio. Se despenca, o working set não cabe — mais RAM, arquivar dados frios, ou revisar índices grandes demais.
• COLLSCAN em produção é quase sempre um índice faltando; caçá-los no profiler é rotina.
• Connection pooling e serverless: revisão do módulo 1 — em Lambda, pool pequeno + client reaproveitado; considere o proxy do Atlas (Data API / drivers com pooling externo).
• Retry storms: retryWrites/retryReads ligados + backoff exponencial com jitter no lado da aplicação. Escrita idempotente (ex.: updateOne com upsert por chave de negócio) é pré-requisito para retry seguro.

9.2 Time Series Collections 5.0+

db.createCollection("leituras", {
  timeseries: { timeField: "ts", metaField: "sensor", granularity: "minutes" },
  expireAfterSeconds: 7776000    // TTL de 90 dias, direto na coleção
})

O MongoDB faz o bucketing por baixo dos panos (compressão colunar, índices otimizados), mas você insere e consulta documentos normais. Use para métricas, IoT, dados financeiros. Limitações: updates/deletes restritos, alguns operadores não suportados — leia a doc antes de adotar como coleção transacional.

9.3 Segurança

• A praga histórica: instâncias abertas na internet sem autenticação causaram milhares de vazamentos e ataques de resgate. Regra: bind em rede privada (VPC peering / private endpoint no Atlas), auth sempre ligada, TLS em trânsito, IP allowlist.
• NoSQL injection: em Node, um corpo { "senha": { "$gt": "" } } passa por um login que faz find(req.body). Defesa: validar tipos (rejeitar objeto onde se espera string), ODM com schema (Mongoose), nunca interpolar entrada em $where/$expr.
• RBAC de menor privilégio: um usuário de banco por serviço, com apenas as ações e coleções necessárias (a API de leitura não recebe insert).
• Encryption at rest (transparente, no storage) e Client-Side Field Level Encryption (CSFLE) / Queryable Encryption: campos sensíveis (CPF, cartão) são cifrados pelo driver, antes de sair da aplicação — o servidor (e o DBA, e um dump vazado) nunca vê o texto claro. Queryable Encryption ainda permite igualdade/faixa sobre o dado cifrado.
• Auditoria: log de acessos e mudanças de schema/role (enterprise/Atlas) para compliance.

9.4 Backup e recuperação

• Réplica não é backup: um deleteMany errado replica na hora para todos os secundários.
• Point-in-Time Recovery (PITR): snapshots periódicos + oplog contínuo permitem restaurar para "3 minutos antes do incidente". Atlas Continuous Backup faz isso; self-hosted, é snapshot de volume + arquivamento do oplog.
• Teste a restauração: "backup que nunca foi restaurado não é backup". Game day trimestral restaurando num ambiente isolado.
• mongodump/mongorestore servem para coleções pequenas e migrações pontuais — não como estratégia de backup de um cluster grande.

9.5 As métricas que você monitora

10.1 O que as vagas realmente testam

10.2 Roadmap por trilha

• Backend / Full-stack: módulos 1–4 são 80% do que cai. Domine CRUD, modelagem, pipeline e índices; depois 6 (concerns) e 8 (Atlas Search). Sharding em nível conceitual.
• Engenharia de Dados: foco em 3 (pipeline), 5 (bucket/time series), 7 (sharding), 8 (Change Streams, Data Federation) e a apostila de Modelagem de Dados NoSQL.
• SRE / DBA: 6, 7 e 9 inteiros — replica set, sharding, tuning, segurança, backup, métricas.
• IA / ML: 8.2 (Vector Search) + a apostila de RAG; MongoDB como store de embeddings e de estado de agentes.

Plano de 6 semanas: sem. 1–2 — módulos 1–2 com um MongoDB local em Docker e uma API CRUD; sem. 3 — módulo 3, reescrever relatórios da API como pipelines; sem. 4 — módulo 4, indexar tudo com explain() antes/depois no README; sem. 5 — módulos 5–6 e migrar o schema uma vez de propósito; sem. 6 — módulos 7–9 em nível conceitual (profundo no da sua trilha) + simulados do 10.3.

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. API de e-commerce (Node/Nest ou FastAPI + MongoDB): catálogo com $facet para listagem+filtros, pedidos com extended reference, índices justificados no README com prints de explain() antes/depois, teste de carga (k6) documentado.
2. Analytics com pipeline + $merge: ingestão de eventos, rollups horários materializados, dashboard que lê da coleção materializada. Diferencial: explicar o custo evitado.
3. Busca híbrida com Atlas Search + Vector Search: um corpus de documentos seus, $search + $vectorSearch, comparando resultados de busca só textual, só vetorial e híbrida com números.
4. Serviço event-driven com Change Streams: um watch() resumível que projeta mudanças de uma coleção para um cache/índice, com tratamento de resumeToken e reconexão.

Em todos: o README explica por que cada decisão de modelagem e índice — recrutador técnico lê README, e a justificativa vale mais que a linha de código.

10.5 Certificação e fontes

• MongoDB Associate Developer e Associate Database Administrator — preparação gratuita e excelente na MongoDB University (trilhas com laboratórios). É a certificação de NoSQL com mais reconhecimento direto.
• Leituras: Designing Data-Intensive Applications (Kleppmann) para a base distribuída dos módulos 6–7; a documentação oficial e o MongoDB Blog (os padrões de schema do módulo 5 vêm de lá, com o mesmo vocabulário).
• Prática permanente: docker run -d -p 27017:27017 mongo para o básico; uma conta gratuita no Atlas (M0) para Search, Vector Search, Triggers e Charts.