Rule-based disposition: any dimension at its most severe tier caps this at “concerns” or worse. Never an averaged score.
- Operational Readiness: Social Feed Platform requires high operational expertise at 'experienced backend team' level. Current readiness estimate is 36%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Architecture Review: Social Feed Platform
A social activity feed architecture where user actions (posts, likes, comments, follows) fan out asynchronously to follower timelines. Redis stores hot feed data as pre-materialized lists per user, enabling O(1) timeline reads for the 99th percentile of users. Kafka carries fan-out work to async workers that write to follower Redis keys. PostgreSQL is the durable store for the social graph, posts, and user content. The system uses a hybrid fan-out model: fan-out-on-write for users with fewer than ~10,000 followers (low fan-out cost), fan-out-on-read for high-follower celebrity accounts where pre-materialized fan-out would saturate workers and Redis write bandwidth.
Evidence Confidence
Moderate
strong
Executive Summary
Social Feed Platform carries moderate operational readiness (81% evidence confidence). 0 architectural strengths identified, 5 operational risks to manage. Primary concern: Queue Backlog Accumulation. Requires Advanced operational maturity.
Readiness Rationale
Overall moderate readiness across 8 dimensions. Limited: scaling, team maturity. Strong: migration, observability, failure recovery.
Key Concerns
- !Queue Backlog Accumulation
- !Thundering Herd
Key Strengths
- +Architecture is well-defined for the event driven system problem profile
8
Assessments
2
Tradeoffs
6
Sections
12
Recommendations
Readiness Assessments
8Governance Posture
6Structural boundary and anti-pattern compliance: whether this architecture's topology violates documented governance policies. Distinct from operational readiness (below), which asks whether the team and infrastructure are prepared to run it.
6 governance policy matches and 0 anti-pattern matches put Social Feed Platform's governance posture at concerning risk. Resilience is moderate; burden is extreme.
6
violations
0
anti-patterns
Governance Violations
Resilience
Blast radius: contained
56%
resilience score
Coupling Risks
- ·Celebrity fan-out storm: a single post from an account with 5M+ followers trigge
- ·Redis memory pressure from feed materialization: at 100M users each with a feed
Consistency Risks
- ·Replication lag on social graph reads: a high-write period (follow/unfollow stor
Resilience Gaps
- △3 high-exposure risk nodes increase blast radius
Operational Burden
operational burden
100%
burden index
Complexity Drivers
- ⚙6 architecture patterns increase configuration surface
- ⚙Celebrity fan-out storm: a single post from an account with 5M+ followers trigge
- ⚙Hot Kafka partition on celebrity user_id: all activity events for a celebrity ac
Observability Burden
- ◎kafka: requires dedicated monitoring instrumentation
- ◎postgresql: requires dedicated monitoring instrumentation
- ◎rabbitmq: requires dedicated monitoring instrumentation
- ◎redis: requires dedicated monitoring instrumentation
Recovery Complexity
- ⟳3 risk propagation path(s) complicate failure recovery
Maturity
Required
AdvancedEstimated
AdvancedGap
No GapThe architecture's required maturity (advanced) aligns with or is below the estimated team capability.
Operational Readiness
7Adoption readiness: whether the team, infrastructure, and observability are prepared to run this architecture safely. Distinct from governance posture (above), which asks whether the topology itself violates architectural boundaries.
Social Feed Platform requires high operational expertise at 'experienced backend team' level. Current readiness estimate is 36%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Readiness Score
36%
Blocking Prerequisites
3
Complexity
High
Confidence
Strong
Assessment derived from scenario knowledge, advisor output, topology analysis, and 7 prerequisite checks.
Prerequisite Checklist (3 blocking, 4 non-blocking)
team
Team at 'experienced backend team' maturity level
This scenario is rated 'experienced backend team' complexity. Engineers with 2+ years of production backend experience, including database tuning and monitoring.
Gap signal: Team frequently reaches for external help during incidents or struggles to debug multi-system issues independently.
process
Failure mode awareness and runbooks
The team must understand the 5 documented failure modes for this scenario: fanout_amplification, thundering_herd, queue_backlog_accumulation, hot_partition. Each should have a documented detection procedure and runbook.
Gap signal: The team has no documented runbooks for the scenario's failure modes or cannot name them without reference material.
monitoring
Production-grade observability stack
The scenario requires real-time metrics, structured logging, and distributed tracing on all critical components. Alerting must be configured before going live.
Gap signal: No dashboards exist for the critical path metrics in the scenario.
infrastructure
Minimum team maturity: Experienced Backend Team
This scenario has high operational complexity. It is recommended for Experienced Backend Team teams or higher.
Gap signal: The requirement 'Minimum team maturity: Experienced Backend Team' is not yet in place.
infrastructure
Runbooks and alerting for high-severity risks
4 high-severity risks identified. Each requires a documented runbook, alerting threshold, and on-call response procedure before running in production.
Gap signal: The requirement 'Runbooks and alerting for high-severity risks' is not yet in place.
infrastructure
Event stream operations expertise
This architecture includes event stream infrastructure (Kafka, Kinesis, or similar). Operations requires consumer group management, partition assignment, dead-letter handling, and lag monitoring.
Gap signal: The requirement 'Event stream operations expertise' is not yet in place.
infrastructure
Mitigation for 1 high-risk topology node(s)
Nodes with high or critical risk exposure: Event Streaming. Each requires documented mitigation before production deployment.
Gap signal: No mitigation strategy is documented for the high-risk nodes in the topology.
Infrastructure Requirements
Apache Kafka
high burdenDistributed event streaming platform designed for high-throughput, fault-tolerant, ordered, and durable log-based messaging between producers and cons
Managed: Amazon MSK (Managed Streaming for Kafka), Confluent Cloud, Azure Event Hubs (Kafka-compatible), Redpanda Cloud
PostgreSQL
medium burdenACID-compliant relational database with strong consistency, JSONB support, full-text search, and mature replication.
Managed: Amazon RDS for PostgreSQL, Amazon Aurora PostgreSQL, Google Cloud SQL for PostgreSQL, Azure Database for PostgreSQL, Supabase, Neon
RabbitMQ
medium burdenAMQP-based message broker with flexible routing (exchanges, queues, bindings), acknowledgment-based delivery, and per-message TTL and dead-letter queu
Managed: CloudAMQP, Amazon MQ for RabbitMQ, Azure Service Bus (AMQP-compatible)
Redis
low burdenIn-memory key-value store with optional persistence, supporting strings, hashes, lists, sets, sorted sets, and pub/sub.
Managed: Amazon ElastiCache for Redis, Google Cloud Memorystore, Azure Cache for Redis, Redis Cloud, Upstash
Observability Requirements
Monitor generic risk probe signals
Seed 'Fanout Amplification Risk Probe' identifies 2 metrics relevant to fanout_amplification.
Seed 'Fanout Amplification Risk Probe' identifies 2 metrics relevant to fanout_amplification.
Monitor queue backlog signals
Seed 'Queue Consumer Backlog' identifies 4 metrics relevant to queue_backlog_accumulation.
Seed 'Queue Consumer Backlog' identifies 4 metrics relevant to queue_backlog_accumulation.
Monitor replication lag signals
Seed 'Replication Lag Under Write Burst' identifies 4 metrics relevant to replication_lag_cascade. Execution preview confirms this risk manifests under modelled load.
Seed 'Replication Lag Under Write Burst' identifies 4 metrics relevant to replication_lag_cascade. Execution preview confirms this risk manifests under modelled load.
Track Thundering Herd exposure
Thundering Herd has high exposure and affects 0 components. Affects 0 nodes
Thundering Herd has high exposure and affects 0 components. Affects 0 nodes
Track Queue Backlog Accumulation exposure
Queue Backlog Accumulation has high exposure and affects 1 component. Affects 1 node. (Event Streaming)
Queue Backlog Accumulation has high exposure and affects 1 component. Affects 1 node. (Event Streaming)
Kafka consumer group lag for fan-out worker group growing steadily; feed propagation latency (time from post write to fo
This signal indicates the architecture is approaching 'Tier 1: Fan-Out Worker Queue Backlog'. Likely bottleneck: Fan-out worker pool undersized for burst post activity or a celebrity post creating a sustained high-fan-out event.
Tier 1: Fan-Out Worker Queue Backlog
Redis memory utilization > 75%; eviction rate rising; cache miss rate on feed reads increasing; cold feed read fallback
This signal indicates the architecture is approaching 'Tier 2: Redis Feed Memory Ceiling'. Likely bottleneck: Redis feed list storage approaching memory limit; feed items being evicted before TTL; or feed list cap set too high for available memory.
Tier 2: Redis Feed Memory Ceiling
PostgreSQL replica lag > 10s during peak fan-out periods; follower list queries appearing in pg_stat_activity with wait_
This signal indicates the architecture is approaching 'Tier 3: Social Graph PostgreSQL Read Pressure'. Likely bottleneck: PostgreSQL replicas unable to serve fan-out worker follower list read volume; replica lag causing stale follower list reads.
Tier 3: Social Graph PostgreSQL Read Pressure
Readiness Action Plan
Satisfy: Team at 'experienced backend team' maturity level
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Social Feed Platform
Satisfy: Failure mode awareness and runbooks
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Social Feed Platform
Satisfy: Production-grade observability stack
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Social Feed Platform
Instrument all critical path components with metrics and alerting
Effort: 1–2 weeks · Unblocks: Safe production adoption and incident response
Validate adoption in a staging environment before production
Effort: 2–4 weeks for thorough staging validation · Unblocks: Production confidence and rollback preparedness
Mitigate risk: Thundering Herd
Effort: 1–3 weeks · Unblocks: Reduces 'Thundering Herd' from blocking adoption
Mitigate risk: Queue Backlog Accumulation
Effort: 1–3 weeks · Unblocks: Reduces 'Queue Backlog Accumulation' from blocking adoption
Go Signals
- ✓Team has hands-on experience with all 4 referenced technologies.
- ✓All scenario failure modes have documented runbooks and alerting coverage.
- ✓A staging environment that mirrors production load has been tested successfully.
No-Go Signals
- ✗Team cannot explain or debug any of Social Feed Platform's documented failure modes.
- ✗No observability baseline exists for the critical components.
- ✗Top risk is unmitigated: 'Thundering Herd', do not proceed without addressing this.
Critical Gaps
- This scenario has high operational complexity, teams without deep production experience will struggle to operate it safely.
Team Requirements
Apache Kafka operations
Required level: proficient
Team can explain Apache Kafka's failure modes, tune configuration parameters under load, and recover from common operational issues.
PostgreSQL operations
Required level: proficient
Team can explain PostgreSQL's failure modes, tune configuration parameters under load, and recover from common operational issues.
RabbitMQ operations
Required level: proficient
Team can explain RabbitMQ's failure modes, tune configuration parameters under load, and recover from common operational issues.
Redis operations
Required level: proficient
Team can explain Redis's failure modes, tune configuration parameters under load, and recover from common operational issues.
Readiness assessment is derived from structured scenario and topology knowledge. It provides an evidence-grounded baseline, not a substitute for an actual team capability review or infrastructure audit. Validate each item against your specific environment.
Architectural Tradeoffs
2Recommendations
12Monitor: Thundering Herd
risk_monitoringWhen a shared outage, network partition, or coordinated recovery event ends, every client, connection, or worker that was waiting or blocked resumes activity at nearly the same instant, producing a synchronized burst of retries, reconnects, or requests that can overwhelm the system just as it is recovering.
Affects 0 nodes
Monitor: Queue Backlog Accumulation
risk_monitoringMessage queue or event stream consumer processing rate falls below producer write rate, causing consumer lag to grow unboundedly: eventually leading to increased end-to-end latency, producer backpressure, data expiry, or queue resource exhaustion.
Affects 1 node. (Event Streaming)
Implement: Monitor generic risk probe signals
observabilitySeed 'Fanout Amplification Risk Probe' identifies 2 metrics relevant to fanout_amplification.
Metrics to instrument: error_rate, p95_latency_ms
Monolithic feed built on PostgreSQL timeline queries → Redis pre-materialized feed with Kafka async fan-out workers
migration_planningTrigger: PostgreSQL timeline read query p99 > 500ms; query plan for "SELECT posts WHERE user_id IN (following_list) ORDER BY created_at DESC LIMIT 50" showing sequential scan or index merge; feed read traffic accounting for > 40% of database CPU. Migrate from 'Monolithic feed built on PostgreSQL timeline queries' to 'Redis pre-materialized feed with Kafka async fan-out workers'. Introduce the Kafka fan-out worker and Redis feed writer in shadow mode for 2–4 weeks before cutting feed reads from PostgreSQL to Redis. Use a 5% traffic canary to validate feed correctness (compare PostgreSQL and Redis results) before full cutover. The outbox pattern on post writes must be in place before Kafka fan-out workers are added.
Redis feed hydration requires a backfill job to populate feed lists for all existing users from historical post data; backfill must be idempotent and rate-limited to avoid Redis write saturation; During the migration period, double-writes (to both PostgreSQL timeline query path and Redis fan-out path) are required; consistency between the two paths must be validated before cutting over read traffic
Uniform fan-out-on-write for all accounts → Hybrid fan-out model (fan-out-on-write for <10k followers, fan-out-on-read for high-follower accounts)
migration_planningTrigger: Fan-out worker queue lag during celebrity post events > 5 minutes; Redis write throughput spiking to > 80% of capacity during these events; fan-out cost for top 100 accounts measured at > 1000x median fan-out cost. Migrate from 'Uniform fan-out-on-write for all accounts' to 'Hybrid fan-out model (fan-out-on-write for <10k followers, fan-out-on-read for high-follower accounts)'. Implement fan-out-on-read as a supplementary merge layer on top of the existing fan-out-on-write path, not a replacement. Feed reads for users following celebrity accounts fetch the celebrity's recent posts directly from PostgreSQL (via Redis cache) and merge them into the pre-materialized feed list at read time.
Fan-out-on-read for celebrity accounts requires feed merge logic at read time (combine pre-materialized follower feed with recent celebrity posts); this merge adds latency and complexity to the feed read path; Threshold for routing (follower count) must be maintained as a dynamic config; hardcoding it causes operational problems when accounts cross the threshold
Prepare runbook for: Burst Traffic Cold Cache Stampede
simulation_preparednessSimulation demonstrates critical degradation of redis, postgresql
Without a runbook, recovery from this failure mode will be ad-hoc
Prepare runbook for: Connection Pool Exhaustion with Horizontal User Scale
simulation_preparednessSimulation demonstrates critical degradation of postgresql
Without a runbook, recovery from this failure mode will be ad-hoc
Plan evolution: OLTP Analytics Queries → OLTP + OLAP Separation
evolution_planningEvolution from Unified OLTP + Analytics on PostgreSQL → Separated OLTP (PostgreSQL) + OLAP (ClickHouse/Snowflake)
Migration complexity: medium. Rollback: always.
Plan evolution: Single Cache Layer → Distributed Cache
evolution_planningEvolution from Single Redis Node / Sentinel Cluster → Distributed Redis Cluster (Consistent Hash Ring)
Migration complexity: medium. Rollback: complex.
Cache-outage database fallback load
caching'Social Feed Platform' includes a cache in its topology. If the cache becomes unavailable, the primary database receives the cache's full request load until the cache recovers.
Capacity-plan the primary database for this fallback load, not only for the steady-state cached load.
Cache invalidation ownership
cachingCache invalidation for Social Feed Platform is event-driven: kafka refreshes or invalidates redis. This couples cache freshness to consumer lag on that event stream, not to the primary write path directly.
If the event-stream consumer falls behind, the cache serves stale data until it catches up -- monitor consumer lag as a cache-freshness signal, not only a backlog signal.
Monitor threshold: Tier 1: Fan-Out Worker Queue Backlog
scaling_monitoringSignal: Kafka consumer group lag for fan-out worker group growing steadily; feed propagation latency (time from post write to follower feed update) exceeding 30s p95; Redis write rate on feed keys elevated but not saturated; post activity rate normal
Bottleneck: Fan-out worker pool undersized for burst post activity or a celebrity post creating a sustained high-fan-out event. Evolution: Add fan-out worker replicas; implement fan-out cost routing: route high-follower-count fan-out events to a dedicated high-cost worker pool with separate Kafka consumer group and Redis write quota; use follower count threshold (e.g., >50k followers) as the routing decision. Monitor fan-out cost per post as a first-class metric.
Scaling Pressure Signals
8Kafka consumer group lag for fan-out worker group growing steadily; feed propagation latency (time from post write to follower feed update) exceeding 30s p95; Redis write rate on feed keys elevated but not saturated; post activity rate normal
Threshold
Tier 1: Fan-Out Worker Queue Backlog
Likely Bottleneck
Fan-out worker pool undersized for burst post activity or a celebrity post creating a sustained high-fan-out event
Recommended Evolution
Add fan-out worker replicas; implement fan-out cost routing: route high-follower-count fan-out events to a dedicated high-cost worker pool with separate Kafka consumer group and Redis write quota; use follower count threshold (e.g., >50k followers) as the routing decision. Monitor fan-out cost per post as a first-class metric.
Redis memory utilization > 75%; eviction rate rising; cache miss rate on feed reads increasing; cold feed read fallback queries appearing in PostgreSQL slow query log; feed read p99 > 100ms despite Redis being online
Threshold
Tier 2: Redis Feed Memory Ceiling
Likely Bottleneck
Redis feed list storage approaching memory limit; feed items being evicted before TTL; or feed list cap set too high for available memory
Recommended Evolution
Reduce feed list cap from current value toward 100–150 items; increase Redis cluster capacity or shard feed keys by user_id range across multiple Redis primaries; implement tiered feed storage: hot recent items in Redis, older items fetched from PostgreSQL on demand with explicit product UX affordance
PostgreSQL replica lag > 10s during peak fan-out periods; follower list queries appearing in pg_stat_activity with wait_event = Lock; read replica CPU > 70%; fan-out worker follower fetch latency rising; incorrect fan-out events (missing recent followers) appearing in feed correctness monitoring
Threshold
Tier 3: Social Graph PostgreSQL Read Pressure
Likely Bottleneck
PostgreSQL replicas unable to serve fan-out worker follower list read volume; replica lag causing stale follower list reads
Recommended Evolution
Materialize hot follower lists in Redis (TTL 60s) to absorb fan-out worker read volume; route all fan-out follower reads through Redis cache-aside before touching PostgreSQL replica; add a dedicated read replica for fan-out worker social graph reads, isolated from timeline API read replicas
Kafka partition consumer lag concentrated on 2–3 partitions; fan-out latency for specific high-follower accounts disproportionately high vs. median; Kafka broker CPU uneven across partitions; single partition throughput ceiling (~100MB/s) visibly constraining fan-out for specific actor IDs
Threshold
Tier 4: Kafka Hot Partition Saturation
Likely Bottleneck
Kafka topic partitioned by actor_id causing all celebrity events to land on one partition, hitting single-partition throughput ceiling
Recommended Evolution
Re-partition fan-out topic by a composite key (actor_id + post_id hash bucket) to distribute celebrity writes across multiple partitions; alternatively, use a separate Kafka topic for high-fan-out events with wider partition count; ensure downstream fan-out workers deduplicate or order correctly when a single post may be processed by multiple partitions
Kafka consumer group lag for fan-out worker group growing steadily; feed propagation latency (time from post write to follower feed update) exceeding 30s p95; Redis write rate on feed keys elevated but not saturated; post activity rate normal
Threshold
Escalation trigger: Fan-out worker pool undersized for burst post activity or a celebrity post creating a sustained high-fan-out event
Likely Bottleneck
Tier 1: Fan-Out Worker Queue Backlog
Recommended Evolution
Monitor: error_rate, p95_latency_ms, queue_depth
Redis memory utilization > 75%; eviction rate rising; cache miss rate on feed reads increasing; cold feed read fallback queries appearing in PostgreSQL slow query log; feed read p99 > 100ms despite Redis being online
Threshold
Escalation trigger: Redis feed list storage approaching memory limit; feed items being evicted before TTL; or feed list cap set too high for available memory
Likely Bottleneck
Tier 2: Redis Feed Memory Ceiling
Recommended Evolution
Monitor: error_rate, p95_latency_ms, queue_depth
PostgreSQL replica lag > 10s during peak fan-out periods; follower list queries appearing in pg_stat_activity with wait_event = Lock; read replica CPU > 70%; fan-out worker follower fetch latency rising; incorrect fan-out events (missing recent followers) appearing in feed correctness monitoring
Threshold
Escalation trigger: PostgreSQL replicas unable to serve fan-out worker follower list read volume; replica lag causing stale follower list reads
Likely Bottleneck
Tier 3: Social Graph PostgreSQL Read Pressure
Recommended Evolution
Monitor: error_rate, p95_latency_ms, queue_depth
Kafka partition consumer lag concentrated on 2–3 partitions; fan-out latency for specific high-follower accounts disproportionately high vs. median; Kafka broker CPU uneven across partitions; single partition throughput ceiling (~100MB/s) visibly constraining fan-out for specific actor IDs
Threshold
Escalation trigger: Kafka topic partitioned by actor_id causing all celebrity events to land on one partition, hitting single-partition throughput ceiling
Likely Bottleneck
Tier 4: Kafka Hot Partition Saturation
Recommended Evolution
Monitor: error_rate, p95_latency_ms, queue_depth
Migration Readiness
12Migration Stages
3Monolithic feed built on PostgreSQL timeline queries → Redis pre-materialized feed with Kafka async fan-out workers
infoMigration trigger: PostgreSQL timeline read query p99 > 500ms; query plan for "SELECT posts WHERE user_id IN (following_list) ORDER BY created_at DESC LIMIT 50" showing sequential scan or index merge; feed read traffic accounting for > 40% of database CPU
Uniform fan-out-on-write for all accounts → Hybrid fan-out model (fan-out-on-write for <10k followers, fan-out-on-read for high-follower accounts)
infoMigration trigger: Fan-out worker queue lag during celebrity post events > 5 minutes; Redis write throughput spiking to > 80% of capacity during these events; fan-out cost for top 100 accounts measured at > 1000x median fan-out cost
Single Redis primary for all feed data → Redis Cluster with feed keys sharded by user_id range
infoMigration trigger: Redis memory utilization approaching 80% of a single node; Redis CPU > 60% sustained on feed write operations; single-node Redis becoming a reliability risk for the entire feed system
Risks
9Redis feed hydration requires a backfill job to populate fee
warningRedis feed hydration requires a backfill job to populate feed lists for all existing users from historical post data; backfill must be idempotent and rate-limited to avoid Redis write saturation
During the migration period, double-writes (to both PostgreS
warningDuring the migration period, double-writes (to both PostgreSQL timeline query path and Redis fan-out path) are required; consistency between the two paths must be validated before cutting over read traffic
Fan-out-on-read for celebrity accounts requires feed merge l
warningFan-out-on-read for celebrity accounts requires feed merge logic at read time (combine pre-materialized follower feed with recent celebrity posts); this merge adds latency and complexity to the feed read path
Threshold for routing (follower count) must be maintained as
warningThreshold for routing (follower count) must be maintained as a dynamic config; hardcoding it causes operational problems when accounts cross the threshold
Redis Cluster changes key access patterns: multi-key operati
warningRedis Cluster changes key access patterns: multi-key operations (MGET across users) must use hash tags or become multiple single-key operations; fan-out workers must be updated to handle cluster slot routing
Initial cluster setup requires rebalancing all existing feed
warningInitial cluster setup requires rebalancing all existing feed keys; this operation must be performed with minimal read disruption to the feed API
Projection lag creates a read-after-write window where users
criticalProjection lag creates a read-after-write window where users see stale data after their own writes. Mitigation: Route immediate post-write reads to the write store (session-scoped write token); accept eventual consistency only for non-user-initiated reads
↗ direct-db-to-cqrsProjection rebuild after schema change can take hours or day
criticalProjection rebuild after schema change can take hours or days on large datasets. Mitigation: Design blue/green projection deployment: build new projection in parallel before switching traffic; test rebuild time in staging
↗ direct-db-to-cqrsCross-service workflows that previously used database transa
criticalCross-service workflows that previously used database transactions now require Saga orchestration. Mitigation: Design idempotent event handlers; implement compensating transactions for every multi-step workflow; test failure injection in staging
↗ modular-monolith-to-event-driven