13) Advanced patterns — detailed guide

1) Define the invariants on the write side - authorization, state transitions, limits, uniqueness, ordering 2) Define the event model (append-only) - examples: PostCreated, PostDeleted, FollowCreated, LikeAdded - rules: event schema is “forever” → versioning/upcasters 3) Choose the event log / stream - Kafka/Kinesis/EventStore - partition strategy (postId or userId) + ordering guarantees 4) Build projections (read models) - timeline store (IDs), post view store (metadata), search index (text) - each projection has its own schema optimized for its query 5) Define consistency + freshness SLA - “post visible in feed within 30s p95” - what happens if projection lags (degrade gracefully) 6) Avoid dual-writes - use Outbox pattern or an event store that is the database 7) Rebuild strategy - drop projection → replay events → rebuild → verify → swap

Write path (commands): • POST /post - validate (auth, limits, spam checks) - append PostCreated(postId, authorId, contentRef, ts, visibility) - publish to stream (or write to outbox then publish) Event log: • topic: posts-events (partition by authorId or postId) Projections: 1) UserTimelineProjection - consumes PostCreated + FollowCreated - builds “timeline IDs” per user (fast read) 2) PostViewProjection - stores post metadata by postId (fast hydrate) 3) SearchProjection - indexes post text/tags into Elasticsearch 4) EngagementProjection - counts likes/comments/views (for ranking features) Read path: • GET /feed - fetch postIds (timeline) - batch-hydrate PostViewProjection - rank + rules - return cursor Rebuild: • if ranking features change, replay events to rebuild projections safely.

1) Identify the workflow goal - “Publish post with media safely and make it visible in feed” 2) Break into steps (each must be idempotent) - step inputs/outputs clearly defined 3) Define compensations per step - what does “undo” mean if step 3 fails? 4) Add timeouts & retry policy - per-step timeout + overall deadline 5) Store saga state - workflow engine state store OR your own (dedupe keys) 6) Observability - step metrics, traces, dead-letter queue, operator runbook

Goal: user posts a video; it becomes visible only if processing & safety checks pass. Orchestrated steps: 1) CreateDraftPost (writes PostDraftCreated) 2) UploadVideo (multipart upload) 3) TranscodeRenditions (240p/480p/720p) 4) SafetyScan (policy/moderation) 5) PublishPost (writes PostPublished) 6) FanoutToFollowers (async) Compensations: • If transcode fails → keep draft hidden + retry • If safety fails → mark post blocked + delete media reference (or quarantine) Why orchestration: • Long-running transcode + explicit timeouts + operator visibility.

Indexing pipeline: 1) ingest documents (posts/users/pages) 2) normalize + analyze (language aware) 3) enrich (entities, synonyms, spam signals) 4) index into shards (replicate for read) Query pipeline: 1) parse query (autocomplete/spell/corrections) 2) retrieve candidates (inverted index) 3) rank (BM25 + signals) 4) filter/facets 5) return results + metrics Define SLAs: • indexing lag (p95) • query latency (p95/p99) • relevance metrics (CTR, zero-result rate)

Indexing: • PostPublished events → SearchProjector → Elasticsearch • Fields: text, hashtags, authorId, language, created_at, engagement_score Query “travel nepal”: 1) retrieve candidates via inverted index 2) rank by BM25 + recency + engagement + personalization 3) apply filters (language, friends-only content if required) Operational contract: • indexing lag SLA = 30–60s • monitor: zero-result rate, p95 latency, top failed queries

1) Choose feed storage model - fan-out, fan-in, or hybrid 2) Define candidate generation - timeline IDs from Redis/Cassandra - special handling for celebrity authors 3) Hydration strategy - batch fetch posts/media - avoid N+1 calls 4) Ranking pipeline - candidates → features → score → post-ranking rules - enforce safety + diversity + freshness 5) Caching strategy - cache feed head (first N IDs) - refresh-ahead / background recompute 6) Protection mechanisms - rate limits, backpressure workers, hot-key mitigation

Write: • Typical users → fan-out into follower timelines (async workers) • Celebrity users → do NOT fan-out to millions; keep in author timeline Read (GET /feed): 1) fetch cached “feed head” IDs for user 2) merge in celebrity timelines (fan-in) if needed 3) batch-hydrate post metadata + media refs 4) rank with features (affinity, engagement, recency) 5) apply rules (no duplicates, diversity, safety) 6) return items + cursor Hot key controls: • worker queues bounded + backpressure • per-celebrity cache of recent posts • cache stampede protection on popular feeds

Store: • compute cellId = H3(lat, lon, resolution) • store by cellId prefix (locality) Query radius: 1) compute covering cells (ring/cover) 2) fetch candidates by cellId prefix 3) precise filter using Haversine distance 4) sort/rank by distance and relevance Scale: • shard by region/cell prefix + hash inside region • use multi-resolution for small vs large radii

Use-case: • Show nearby events/posts in the home feed Storage: • event location → H3(r8) cellId Query: • user location → k-ring cells → fetch candidate event IDs • Haversine filter → rank (distance + popularity + personalization) Scaling: • shard by H3 prefix to avoid global scans

Upload: 1) multipart upload to object store 2) transcode renditions (ABR) 3) publish manifests + segments Delivery: • CDN caches versioned URLs (long TTL) • origin shield reduces origin hits • signed URLs for private content • range requests for video seeking Measure: • CDN hit rate, startup time, rebuffer %, origin errors, transcode backlog

Pipeline: • upload → transcode → HLS playlist + 4–6s segments • store segments with versioned URLs (cache safe) Playback: • ABR chooses bitrate per bandwidth • CDN + shield handles viral spikes without crushing origin Cost: • monitor egress spikes and low cache hit rate, pre-warm only truly hot videos

1) Make charges/refunds idempotent - Idempotency-Key + unique constraints 2) Record effects in immutable double-entry ledger - debit/credit lines are append-only 3) Materialize balances for reads - do not mutate ledger rows 4) Reconcile - nightly compare ledger totals to PSP/bank reports - exceptions queue + runbooks 5) FinOps hooks - tag costs, budgets, anomaly detection (egress, hot shards)

Ads billing: • impressions/clicks → aggregate → charge advertiser (idempotent) Ledger: • debit advertiser / credit platform revenue • balances are materialized views Recon: • nightly compare to payment provider reports • mismatches go to ops queue FinOps: • track major costs: CDN egress, storage, ML inference • alert on sudden egress spikes during viral events

Definitions: • Feature store = registry + offline store + online store • Goal: same features in training and serving, with freshness SLAs Flow: 1) offline compute (warehouse/lake) 2) online serve (KV/Redis) with TTL + fast lookup 3) online inference: candidates → feature fetch → score → rules Safety: • shadow traffic, canary cohorts, rollback switch • drift monitoring (input/output), latency SLO monitoring

Ranking: • candidates → fetch features (affinity, engagement, freshness, author quality) • online KV returns < 10ms p95 • model score + rule layer Freshness: • some features near-real-time (recent interactions) • others daily batch (author quality) Rollout: • shadow 5% traffic to new model • canary 1% cohort • rollback if CTR drops or latency breaches

Structure your explanation like this: 1) Source of truth (events or DB) 2) Derived views (projections for fast reads) 3) Async pipelines (fan-out, indexing, counters) 4) Serving layer (caches/CDN, pagination) 5) Ranking layer (features + model + rules) 6) Safety/ops (SLAs, retries, monitoring, rollback) One-line summary: • “Writes are correct, reads are fast, pipelines are async, and rollouts are safe.”

1) Post/like/follow events are appended (audit + replay). 2) Projections build timelines, post views, search index, and counters. 3) Feed read uses timeline IDs → hydrate → rank → rules. 4) Celebrities handled via fan-in; typical users via fan-out. 5) Media served via CDN with ABR; viral spikes protected by caches/shields. 6) Ranking uses feature store and safe rollout (shadow/canary + rollback).

“For the Home Feed, we write events, build projections for timelines and search, hydrate in batches, rank with a feature store, and serve media via CDN—using hybrid fan-out/fan-in to handle celebrities and viral spikes safely.”