# ❌ Broken pattern: using Redis as a durable primary store without persistence
# Default Redis config: no persistence, no AOF, no RDB
# Any crash → total data loss

# ✅ Correct: enable AOF persistence before storing any data you cannot lose
# redis.conf:
appendonly yes
appendfsync everysec          # Flush to disk every second — at most 1 second of data loss
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Key naming: {entity}:{id}:{attribute} — namespaced, scannable, evictable
SET user:42:session '{"role":"admin","expires":1756512000}' EX 86400

# Hash vs. String for session objects:
# ❌ String — requires full JSON round-trip on every field access
SET user:42:session '{"role":"admin","cartSize":3,"lastSeen":"2026-08-30"}'
# Must deserialize entire blob to read just "role"

# ✅ Hash — field-level GET/SET without full deserialization
HSET user:42:session role admin cartSize 3 lastSeen "2026-08-30"
HGET user:42:session role   # reads ONE field, no deserialization overhead
HINCRBY user:42:session cartSize 1  # atomic increment without read-modify-write

# Rate limiting: sliding window using a Sorted Set
ZADD ratelimit:ip:1.2.3.4 1725000000000 "req-uuid-abc"  # score = current timestamp ms
ZREMRANGEBYSCORE ratelimit:ip:1.2.3.4 0 1724999940000   # remove entries older than 1 min
ZCARD ratelimit:ip:1.2.3.4                               # count requests in window

// RedisJSON: document store inside Redis
await client.json.set('product:42', '$', {
  name: 'Wireless Headphones',
  price: 99.99,
  specs: { battery: '30h', bluetooth: '5.2' }
})
const price = await client.json.get('product:42', { path: '$.price' })

// RediSearch: full-text search index on JSON documents
await client.ft.create('idx:products', {
  name: { type: SchemaFieldTypes.TEXT, WEIGHT: 5 },
  'specs.bluetooth': { type: SchemaFieldTypes.TAG }
}, { ON: 'JSON', PREFIX: 'product:' })

const results = await client.ft.search('idx:products', 'wireless @specs.bluetooth:{5\\.2}')

Document: "PostgreSQL is an advanced open-source relational database"

Inverted Index (simplified):
  "postgresql"  → [doc_1, doc_4, doc_12]
  "advanced"    → [doc_1, doc_7, doc_33]
  "open-source" → [doc_1, doc_2, doc_15]
  "relational"  → [doc_1, doc_6, doc_8, doc_21]
  "database"    → [doc_1, doc_2, doc_3, ...]

Query: "open source relational database"
  → intersection of posting lists → [doc_1, doc_2, doc_6, ...]
  → scored by BM25 (term frequency × inverse document frequency)
  → doc_1 scores highest (all terms present)

// ❌ Broken: dynamic mapping — Elasticsearch infers field types on first document
// If document 1 has { "price": 10 } and document 2 has { "price": "ten" }
// Elasticsearch throws a mapping conflict exception at document 2 — field type locked

// ✅ Correct: explicit mapping defined at index creation
PUT /products
{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "name":     { "type": "text", "analyzer": "english" },
      "category": { "type": "keyword" },
      "price":    { "type": "float" },
      "tags":     { "type": "keyword" },
      "description": {
        "type": "text",
        "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }
      }
    }
  }
}

# ILM policy: hot → warm → cold → delete based on index age
PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":   { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
      "warm":  { "min_age": "30d", "actions": { "shrink": { "number_of_shards": 1 } } },
      "cold":  { "min_age": "90d", "actions": { "freeze": {} } },
      "delete":{ "min_age": "365d","actions": { "delete": {} } }
    }
  }
}

Write path (why Cassandra writes are fast):
  1. Write → Commit Log (sequential disk append — durability guarantee)
  2. Write → MemTable (in-memory sorted structure — fast)
  3. MemTable full → flush to SSTable (immutable sorted file on disk)
  4. Background compaction: merge SSTables → remove tombstones → reduce read amplification

Read path (why Cassandra reads can be slow):
  1. Check MemTable (newest data)
  2. Check each SSTable in order (oldest to newest) — read amplification
  3. Bloom filter eliminates most SSTable checks (~95% miss rate)
  4. Merge results across surviving SSTables

-- ❌ Broken: modeling by entity like a relational database
CREATE TABLE users (
  user_id UUID PRIMARY KEY,
  name TEXT,
  email TEXT
);
-- Reading "all orders for a user" requires ALLOW FILTERING — full cluster scan

-- ✅ Correct: model by query — the table shape IS the query
-- Query: "Get all events for a sensor, ordered by time, for the last 7 days"
CREATE TABLE sensor_events (
  sensor_id  UUID,
  event_date DATE,
  ts         TIMESTAMP,  -- clustering column: ordered within partition
  value      DOUBLE,
  PRIMARY KEY ((sensor_id, event_date), ts)  -- composite partition key
) WITH CLUSTERING ORDER BY (ts DESC)
  AND default_time_to_live = 604800;  -- auto-expire after 7 days

-- Query is now a partition scan — no ALLOW FILTERING, no cross-node scatter
SELECT ts, value FROM sensor_events
WHERE sensor_id = ? AND event_date = ?
ORDER BY ts DESC LIMIT 1000;

// ❌ Broken: modeling a recommendation query as SQL joins
// "Find products purchased by users who also bought product X"
SELECT DISTINCT p2.name
FROM orders o1
JOIN order_items i1 ON o1.id = i1.order_id
JOIN order_items i2 ON i1.product_id != i2.product_id
JOIN orders o2 ON i2.order_id = o2.id AND o1.user_id = o2.user_id
JOIN products p2 ON i2.product_id = p2.id
WHERE i1.product_id = 'prod_headphones'
-- At 10M orders: 4-table join → seconds. At 100M: impractical.

// ✅ Correct: Cypher graph traversal — native pattern matching on relationships
MATCH (p1:Product {id: 'prod_headphones'})<-[:PURCHASED]-(:User)-[:PURCHASED]->(p2:Product)
WHERE p1 <> p2
RETURN p2.name, COUNT(*) AS frequency
ORDER BY frequency DESC
LIMIT 10
// At 10M orders: milliseconds. The graph index traverses edges, not table rows.

// Node label granularity: one label per conceptual entity type
CREATE (:User {id: 'u42', name: 'Alice', country: 'DE'})
CREATE (:Product {id: 'p_headphones', name: 'Wireless Headphones', price: 99.99})
CREATE (:Category {name: 'Electronics'})

// Relationships: model in the direction of the dominant traversal query
// Query: "what did this user buy?" → (User)-[:PURCHASED]->(Product)
MATCH (u:User {id: 'u42'})-[:PURCHASED]->(p:Product)

// Query: "who bought this product?" → traverse same edge in reverse — Cypher handles both directions
MATCH (p:Product {id: 'p_headphones'})<-[:PURCHASED]-(u:User)

// ❌ Anti-pattern: storing tabular data in Neo4j nodes and querying without traversal
MATCH (u:User) WHERE u.country = 'DE' RETURN u
// This is a property scan — no graph traversal, no edge following
// This is a relational query wearing a graph costume — use Postgres instead

from openai import OpenAI
client = OpenAI()

# Text → embedding: a 1536-dimension dense vector representing semantic meaning
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="PostgreSQL is an advanced relational database"
)
embedding = response.data[0].embedding  # list of 1536 floats

# Two semantically similar sentences produce similar vectors (high cosine similarity)
# Two unrelated sentences produce dissimilar vectors (low cosine similarity)
# This is why vector search finds relevant content without exact keyword matching

Documents
    │
    ▼
[Chunking]  ← 512-token recursive character splitting (defensible default)
    │
    ▼
[Embedding Model]  ← text-embedding-3-small (1536-dim) or sentence-transformers
    │
    ▼
[Vector Store Upsert]  ← pgvector (< 10M), Qdrant / Pinecone (> 10M)
    │
[At query time:]
    │
    ▼
[Query Embedding]  ← same model as at index time
    │
    ▼
[ANN Retrieval]  ← top-K similar chunks by cosine distance
    │
    ▼
[Context Assembly]  ← inject retrieved chunks into LLM prompt
    │
    ▼
[LLM Response]