1) Componentes centrais: do cluster ao commitlog o mapa mental

Para dominar Cassandra, você precisa entender o que acontece por trás de uma operação. Pense em camadas:

• Cluster: reúne nós com metadados e configurações. Ele orquestra descoberta, replicação e fluxo de dados entre nós.
• Keyspaces: o “namespace” lógico onde você define replication strategy, durabilidade e parâmetros de escrita/leitura.
• Tables (column families): o desenho dos dados que você modela para as consultas mais importantes.
• Memtable + SSTables: mudanças primeiro ficam na memória; depois são imutabilizadas em SSTables (arquivos).
• Commitlog: garante durabilidade do que foi recebido. Se o nó cair, ele consegue se recuperar.

Um detalhe que faz diferença: o formato dos dados em SSTables e o fluxo de compactação influenciam custo de I/O.
Por isso, arquitetura e modelagem não são temas separados — são o mesmo sistema visto de ângulos diferentes.

2) Distribuição e tolerância a falhas: particionamento e replicação sem “mágica”

O que torna o cluster “distribuído” na prática é a combinação de:

• Particionamento via partition key: define onde os dados daquele conjunto “moram” no anel.
• Token ring: cada nó assume um conjunto de tokens; isso decide responsabilidade pelos dados.
• Replicação: cada dado é copiado para múltiplos nós (fator de replicação) usando uma estratégia.

Em termos de disponibilidade, Cassandra costuma ser forte porque a replicação permite continuar atendendo mesmo com nós fora.
Mas para consistência, você precisa escolher o nível adequado de acordo com o risco que aceita.

3) Modelo de dados orientado a consultas: chave de partição e ordenação a regra de ouro

Cassandra exige que você modele a tabela pensando nas suas consultas, não no “relacionamento” clássico.
O mecanismo mais importante é a partition key:

• Consultas eficientes normalmente conseguem começar por uma partition key definida.
• Dentro da partição, o clustering (ordem por colunas de clustering) define como os dados serão varridos.
• Sem uma partition key (ou com valores que geram partições gigantes), você tende a disparar leituras distribuídas.

Para dominar, eu sempre verifico três pontos:

• Cardinalidade da partition key: ela deve distribuir carga, não concentrar.
• Granularidade temporal (se existir tempo): muitas vezes a chave de partição precisa “quebrar” volumes.
• Tamanho e crescimento da partição: uma partição que cresce sem controle vira gargalo.

4) Consistência, leitura/escrita e compactação: onde a arquitetura aparece no dia a dia tuning com intenção

Você controla consistência via níveis (ex.: ONE, QUORUM, ALL) tanto para escrita quanto para leitura.
Esse ajuste conversa diretamente com latência, durabilidade e o que acontece em falhas parciais.

Em alto nível:

• Escritas: o nó coordenador encaminha para réplicas, e o nível escolhido define quando a operação é considerada concluída.
• Leituras: o nível de leitura determina quantas réplicas precisam responder para você receber o resultado.

Exemplo prático: desenho de tabela e estratégia de consistência DDL + leitura orientada

Abaixo está um exemplo didático: eu desenho a tabela para leituras por usuário em janelas de tempo.
Note como a partition key inclui um componente temporal para evitar partições gigantes e hotspots.

-- Keyspace com replicação (exemplo simples; ajuste para seu cenário real)
CREATE KEYSPACE IF NOT EXISTS app_analytics
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'datacenter1': 3
}
AND durable_writes = true;

-- Tabela modelada para "ler eventos por usuário em um intervalo"
-- A partition key é (user_id, day) para distribuir e limitar crescimento.
CREATE TABLE IF NOT EXISTS app_analytics.user_events_by_day (
  user_id uuid,
  day date,
  event_time timestamp,
  event_type text,
  payload text,

  PRIMARY KEY ((user_id, day), event_time)
)
WITH CLUSTERING ORDER BY (event_time DESC);

-- Consulta típica: sempre usa a partition key (user_id, day)
-- e aproveita o clustering para retornar os eventos mais recentes.
-- (No driver/linha da aplicação, você controla limites e paginação.)
SELECT event_time, event_type, payload
FROM app_analytics.user_events_by_day
WHERE user_id = ?
  AND day = ?
LIMIT 50;

-- Em consultas com nível de consistência controlado via driver/consulta,
-- o objetivo é alinhar disponibilidade e consistência com sua tolerância a falhas:
-- Exemplo (conceitual): QUORUM para reduzir risco em falhas parciais.