Antipadrões de modelagem no MongoDB

Resposta esperada

(1) Arrays sem limite (massive arrays) — `comentarios: [...]` num post que pode ter milhares: o documento cresce, passa a realocar, chega perto dos 16 MB, e atualizar um item fica caro. Use uma coleção separada com referência, ou embuta só os N mais recentes. (2) Muitas coleções pequenas / uma coleção por tenant — não escala em metadados e índices. (3) 'Bloated documents' — carregar campos gigantes (um blob, histórico completo) que quase nenhuma query usa; separe. (4) Índice pra tudo — cada índice custa em escrita e RAM; índice não usado é só peso (`$indexStats` mostra). (5) Modelar como relacional — tudo normalizado com referências e um `$lookup` em toda query, jogando fora a vantagem do documento. (6) Usar `_id` aleatório sem necessidade quando um natural serviria. O fio condutor: modelar por como o app lê, e vigiar o crescimento não-limitado.