Questão de Banco de Dados — Família de Colunas (Cassandra) — FCC 2025

Banco de Dados NoSQL: escolha do modelo para alta ingestão e baixa latência

Gabarito: letra E. O cenário exige ingestão em massa de 200 milhões de transações diárias, alta disponibilidade, baixa latência e escalabilidade horizontal — características que definem o Apache Cassandra, um NoSQL orientado a colunas (família de colunas) com arquitetura distribuída e descentralizada. As demais alternativas apresentam modelos inadequados para o caso: grafos (foco em relacionamentos), relacional (consistência forte, mas complexidade de sharding manual), chave-valor (Redis é in-memory, não para persistência analítica) e documentos (flexibilidade de esquema, mas não é o mais indicado para essa carga massiva de escrita).

O problema central é identificar qual modelo de banco de dados atende a um cenário de alta taxa de escrita, baixa latência e escalabilidade horizontal. O Apache Cassandra foi projetado exatamente para isso: é um banco NoSQL orientado a colunas, distribuído, descentralizado (sem nó mestre), que oferece alta disponibilidade e escala linear adicionando-se mais nós ao cluster. Ele é amplamente usado em sistemas que precisam processar milhões de transações por segundo, como redes sociais e plataformas de e-commerce.

Para entender a escolha, é essencial conhecer os quatro grandes modelos NoSQL e seus casos de uso típicos:

O Cassandra se destaca no cenário da questão porque foi desenhado para altíssima taxa de escrita, replicação multi-nó/região e escala linear. Sua arquitetura descentralizada (peer-to-peer) elimina o gargalo de um nó mestre, garantindo alta disponibilidade mesmo com falhas em nós individuais. Além disso, a baixa latência é alcançada porque os dados são gravados em memória e em log, com consistência eventual configurável.

A pegadinha da banca está em associar o cenário de detecção de fraudes ao banco de grafos (alternativa A). Embora grafos sejam excelentes para detectar padrões complexos de relacionamento, eles não são projetados para ingestão massiva em tempo real — o próprio material de apoio indica que grafos "não trabalham em tempo real". A detecção de fraudes aqui é uma consulta rápida sobre dados já armazenados, não a modelagem de relacionamentos complexos. O requisito dominante é a ingestão em alta velocidade, que aponta diretamente para o modelo colunar.

Outra distinção importante: o Redis (alternativa C) é um banco chave-valor in-memory, extremamente rápido para cache, mas não é adequado para armazenamento permanente de transações nem para consultas analíticas complexas. O MongoDB (alternativa D) oferece flexibilidade de esquema, mas não é a escolha clássica para cargas massivas de escrita com alta disponibilidade distribuída — o Cassandra é o padrão de mercado para esse cenário.

Guarde o critério decisivo: quando a questão falar em ingestão massiva, alta disponibilidade, baixa latência e escalabilidade horizontal, o modelo colunar (Cassandra) é a resposta. É exatamente nesse ponto que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O Neo4j é um banco de dados orientado a grafos, excelente para modelar relacionamentos e detectar padrões complexos (como fraudes em redes de relacionamento). Porém, o cenário exige ingestão em massa de 200 milhões de transações diárias com alta disponibilidade e baixa latência — requisitos que grafos não atendem bem. O material de apoio reforça que grafos "não trabalham em tempo real", o que contraria a necessidade de consultas rápidas para detecção de fraudes em tempo quase real. O erro está em priorizar o aspecto de detecção de fraudes e ignorar o requisito dominante de alta taxa de escrita.

Alternativa B — ❌ Incorreta

Um banco relacional com replicação e sharding manual poderia, em tese, escalar, mas com maior complexidade operacional e sem a mesma eficiência para cargas massivas de escrita. Bancos relacionais priorizam consistência (ACID), o que impõe overhead e limita a escalabilidade horizontal quando comparados a soluções NoSQL distribuídas. O cenário pede alta disponibilidade e baixa latência — características mais naturais em bancos NoSQL colunares como o Cassandra. A alternativa contraria o requisito de simplicidade e desempenho para ingestão massiva.

Alternativa C — ❌ Incorreta

O Redis é um banco chave-valor in-memory, projetado para cache, sessões e filas — não para armazenamento permanente de transações nem para consultas analíticas. Dados no Redis são voláteis (armazenados na RAM), o que não atende à necessidade de persistência de dados fiscais detalhados. Além disso, consultas analíticas complexas não são o forte do modelo chave-valor, que se limita a buscas por chave. A alternativa confunde o caso de uso de cache com o de armazenamento transacional massivo.

Alternativa D — ❌ Incorreta

O MongoDB é um NoSQL orientado a documentos, com esquema flexível e indexação em JSON/BSON. Embora seja escalável, não é a escolha clássica para ingestão massiva com altíssima taxa de escrita e alta disponibilidade distribuída — o Cassandra é o padrão para esse cenário. O MongoDB se destaca em aplicações com dados semiestruturados e esquema variável, mas o requisito dominante aqui é a velocidade de escrita e escala linear, que aponta para o modelo colunar. A alternativa não atende plenamente ao cenário descrito.

Alternativa E — ✅ Correta ⟵ GABARITO

O Apache Cassandra é um NoSQL orientado a colunas, com arquitetura distribuída e descentralizada (sem nó mestre), projetado para altíssima taxa de escrita, baixa latência, replicação multi-nó/região e escala linear. Ele é a escolha ideal para o cenário de 200 milhões de transações diárias com alta disponibilidade e consultas rápidas. O material de apoio confirma: "O Cassandra/Scylla (família wide-column, LSM-tree) foi desenhado para altíssima taxa de escrita, baixa latência, replicação multi-nó/região e escala linear". A alternativa espelha exatamente os requisitos do enunciado.

Gabarito: letra E