---
# System prepended metadata

title: "\U0001F6F8 Desafio Cassandra — UFology Tracker"

---

#  Desafio Cassandra — UFology Tracker

![u3828981747_ultra_realistic_cinematic_scene_of_a_data_enginee_bc05ac31-f5e7-40e0-91a9-4018057bbc69_0-min](https://hackmd.io/_uploads/ry8BRlo6ex.png)

## Capítulo 1 – O Chamado

O planeta inteiro observa o céu.  
Milhares de relatos de luzes misteriosas chegam a cada hora.  
O **UFology Tracker** nasceu para isso: registrar, cruzar, filtrar e entender o impossível.

Mas há um problema.

O volume de dados é tão grande que o modelo relacional entrou em colapso.  
JOINs intermináveis.  
Relatórios que demoram mais do que uma noite estrelada.  

É hora de remodelar o sistema — agora em **Cassandra**.

---

## Capítulo 2 – A Missão

Você foi convocado para reestruturar o banco de dados dos investigadores.  
O desafio é simples de enunciar e brutal de resolver:

**Cada consulta precisa ter sua própria tabela otimizada.**

Nada de JOIN.  
Nada de agregação em tempo real.  
Tudo deve nascer pronto para ser lido.

Os cientistas pedem que o sistema responda rapidamente às seguintes perguntas:

1. Últimos **N avistamentos por UF**, ordenados por data.  
2. **Timeline** completa de uma testemunha específica.  
3. **Top locais** com mais avistamentos e média de confiabilidade.  
4. Avistamentos **por tipo + região + dia**.  
5. **Evidências** associadas a um avistamento.  
6. **Telemetria**: últimas leituras de sensores por local.  
7. Remover automaticamente (TTL) relatos de **baixa confiabilidade**.

Seu papel: **criar as tabelas que tornam essas queries possíveis**.

---

## Capítulo 3 – As Condições do Campo

O domínio é vasto, mas as regras são claras:

- Cada avistamento possui uma identificação única, data, tipo e nível de confiabilidade.  
- Cada testemunha tem nome, reputação e cidade.  
- Cada local possui coordenadas e região (UF, geohash).  
- Cada evidência pertence a um único avistamento.  
- Cada leitura de sensor pertence a um local e chega em intervalos curtos.

O sistema precisa lidar com **milhares de inserções por segundo**,  
permitindo consultas rápidas e previsíveis, sem sobrecarregar o cluster.  

E mais: os relatos de baixa confiabilidade devem **sumir automaticamente** após um tempo.  
O banco precisa se limpar sozinho, como o próprio céu depois da tempestade.

---

## Capítulo 4 – O Desafio

Implemente o modelo Cassandra que suporte todas as queries do capítulo anterior.

Para cada consulta, defina:
- Quais colunas estarão disponíveis.  
- Qual será a **chave de partição**.  
- Qual será a **ordenação de clustering**.  
- Quais colunas adicionais serão duplicadas para evitar JOINs.  
- Quais linhas terão **TTL** configurado.  

O objetivo é construir um modelo que permita leitura direta, rápida e previsível.  
Nenhuma query deve precisar de “pensamento” — a tabela certa já é a resposta.

---

## Capítulo 5 – O Desenho do Chebotko

Agora é sua vez de **visualizar o modelo**.  
Antes de criar as tabelas no Cassandra, desenhe o **Chebotko Diagram** completo do UFology Tracker.  

Seu diagrama deve mostrar:
- As entidades originais (Testemunha, Local, Avistamento, Evidência, LeituraSensor).  
- As **tabelas de consulta** derivadas de cada pergunta.  
- As **chaves de partição e clustering** de cada tabela.  
- As setas indicando a origem dos dados (quem alimenta quem).  
- As duplicações necessárias para eliminar JOINs.

Use qualquer ferramenta que desejar (draw.io, Lucidchart, papel, ou ASCII).  
A ideia é **enxergar o trade-off** entre consistência e velocidade.

> “No Cassandra, o diagrama é o mapa das perguntas, não o mapa do mundo.”

---

## Capítulo 6 – O Céu em Movimento

Depois de desenhar o Chebotko e projetar suas tabelas,  
gere dados simulados de avistamentos e valide se cada query funciona.  
Cada tabela deve responder **uma pergunta específica** —  
nada de improvisar.

Quando o sistema estiver rodando,  
você verá o rastreador funcionando como um radar:  
rápido, silencioso, preciso.

---

## Capítulo 7 – O Sinal

O céu volta a se iluminar.  
Os pesquisadores visualizam timelines, mapas de calor e estatísticas de confiabilidade.  
Os relatos fracos se apagam com o tempo.  
O sistema permanece leve, distribuído e previsível.

Você acaba de concluir sua primeira **modelagem por query flow**,  
materializada num **Chebotko Diagram** digno de um engenheiro interplanetário.

---

**Fim da transmissão.**  
O próximo lote de dados chega em 10 segundos.  
Certifique-se de que o seu Chebotko esteja pronto.
