cv defence infra tools

Kafka — why Kafka (vs a normal queue)?

It's a durable, replayable log, and multiple independent consumer groups can each read the whole stream (vs a queue where a message is consumed once). Replay + fan-out to many consumers is the point.

Kafka — ordering guarantee

Ordering holds PER PARTITION only, not across a topic. Key by the entity (all events for user X → same partition). Caveat: even within a partition, producer retries with max.in.flight>1 can reorder unless enable.idempotence=true. Cross-partition order is never guaranteed.

Kafka — delivery semantics + my real story

Default is at-least-once → duplicates possible → consumers must be IDEMPOTENT. My moderation pipeline: idempotent incremental re-moderation, so replays/dupes don't double-act. Real, walkable story.

Redis — data structure → use case

ZSET (sorted set) = leaderboard / rate-limit / priority · hash = object fields · list = queue/stack · set = membership/dedup · string = counter/cache. "Pick the structure that makes the operation O(log n) or O(1)."

Redis — cache-aside pattern

Read: check cache → miss → read source-of-truth → write to cache with a TTL → return. Write: update DB, then invalidate/update cache. Most common caching pattern; know it cold.

Redis — persistence RDB vs AOF

RDB = periodic point-in-time snapshots (compact, fast restart, can lose recent writes). AOF = append-only log of every write (durable, larger, slower replay). Often run both.

Redis — eviction

DEFAULT is noeviction — at maxmemory, writes are rejected while reads still work. For a cache you configure allkeys-lru / allkeys-lfu / volatile-ttl. Depth note: Redis LRU/LFU are APPROXIMATE — they sample N keys (maxmemory-samples), not a true global order.

Docker — image vs container vs layer

Image = read-only template (built from layers). Container = a running instance of an image (+ a writable layer). Layer = one cached filesystem diff per Dockerfile instruction.

Docker — layer-cache ordering trick

Copy + install dependencies BEFORE copying app code, so a code change doesn't bust the (slow) dependency-install layer. Order instructions least-changing → most-changing.

Docker — why containerize ML?

Reproducibility + escape dependency hell (pin the exact CUDA/torch/lib stack). Also: multi-stage builds shrink images; the container filesystem is ephemeral → use volumes for anything you must keep.

Kubernetes — how do I answer depth questions?

Lead with the honest boundary: "I deploy onto clusters; I haven't operated them." Know pod/deployment/service, replicas/HPA scaling, kubectl get/logs/describe/exec. Do NOT overclaim RBAC/CNI/etcd — overclaiming is the documented trap; the honest boundary IS the strong answer.

FastAPI — async def vs def endpoints

async def runs on the event loop (use for async I/O; never block it with sync calls). def runs in a threadpool (safe for sync/blocking work). Blocking the event loop with sync I/O in an async endpoint is the classic bug.

FastAPI — heavy work + inference

Don't do heavy CPU/long jobs inline — offload to Celery/a task queue (BackgroundTasks is only for light fire-and-forget). For inference, batch requests to use the GPU efficiently.

FastAPI — dependency injection

Declare shared resources (DB session, auth, settings) as params via Depends(); FastAPI resolves the graph per request and caches within that request. Killer feature for testing: dependency_overrides swaps real deps for fakes.

Triton — the depth to shore up

Dynamic batching (server groups concurrent requests into one batched inference for throughput) · multi-model GPU-memory sharing / GPU scheduling · basic sharding. I run Python + ONNX backends; defend that, calibrate depth honestly.

Elasticsearch / Qdrant — go-deep triggers

Only fire on RAG/search roles. Then: HNSW vs IVF (graph vs inverted-list ANN indexes), quantization (shrink vectors, trade recall for memory/speed), hybrid search (BM25 + vectors + RRF — I built this at Metro).

XGBoost — the defend-it points

Boosting (sequential, each tree fixes prior errors, ↓bias) vs bagging (parallel, ↓variance). 2nd-order optimization (uses gradient + Hessian). Regularization: α (L1), λ (L2), γ (min split gain). Tune depth/lr/n_estimators + early stopping to control overfit.