Rule-based disposition: any dimension at its most severe tier caps this at “concerns” or worse. Never an averaged score.
- Operational Readiness: Two-Sided Marketplace Platform requires expert operational expertise at 'platform engineering team' level. Current readiness estimate is 20%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Architecture Review: Two-Sided Marketplace Platform
A two-sided marketplace architecture serving buyers, sellers, listings, transactions, search, and notifications from a shared infrastructure, where multiple independent domains must coordinate without tight coupling. Event sourcing captures every state transition; the saga pattern orchestrates multi-step transactions (create order, reserve inventory, charge payment, notify seller) with compensating transactions for partial failures. Kafka decouples domain event publication from consumption; RabbitMQ handles notification fanout; Elasticsearch serves listing search; Redis caches listing display and session state.
Evidence Confidence
Moderate
moderate
Executive Summary
Two-Sided Marketplace Platform carries moderate operational readiness (80% evidence confidence). 0 architectural strengths identified, 5 operational risks to manage. Primary concern: Cascading Failure. Requires Advanced operational maturity.
Readiness Rationale
Overall moderate readiness across 8 dimensions. Limited: scaling, team maturity. Strong: migration, observability, failure recovery.
Key Concerns
- !Cascading Failure
- !Hot Partition
Key Strengths
- +Architecture is well-defined for the marketplace platform problem profile
8
Assessments
5
Tradeoffs
6
Sections
12
Recommendations
Readiness Assessments
8Governance Posture
5Structural 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.
5 governance policy matches and 1 anti-pattern match put Two-Sided Marketplace Platform's governance posture at concerning risk. Resilience is limited; burden is extreme.
5
violations
1
anti-patterns
Governance Violations
Anti-Pattern Matches
Resilience
Blast radius: contained
45%
resilience score
Coupling Risks
- ·Cascading failure from payment service degradation: a slow payment processor cau
- ·Saga compensation cascade: a partial failure in the payment step leaves inventor
Consistency Risks
- ·Elasticsearch listing index staleness: high seller update volume causes CDC cons
Resilience Gaps
- △5 high-exposure risk nodes increase blast radius
Operational Burden
operational burden
100%
burden index
Complexity Drivers
- ⚙6 architecture patterns increase configuration surface
- ⚙Saga compensation cascade: a partial failure in the payment step leaves inventor
- ⚙Hot listing thundering herd: a viral listing receiving simultaneous traffic from
Observability Burden
- ◎elasticsearch: requires dedicated monitoring instrumentation
- ◎kafka: requires dedicated monitoring instrumentation
- ◎postgresql: requires dedicated monitoring instrumentation
- ◎rabbitmq: requires dedicated monitoring instrumentation
Recovery Complexity
- ⟳1 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.
Two-Sided Marketplace Platform requires expert operational expertise at 'platform engineering team' level. Current readiness estimate is 20%, critical gaps must be resolved before adoption. Consider starting with a simpler scenario and evolving toward this one.
Readiness Score
20%
Blocking Prerequisites
3
Complexity
Expert
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 'platform engineering team' maturity level
This scenario is rated 'platform engineering team' complexity.
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: hot_partition, cascading_failure, lock_contention, thundering_herd. 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: Platform Engineering Team
This scenario has expert operational complexity. It is recommended for Platform Engineering Team teams or higher.
Gap signal: The requirement 'Minimum team maturity: Platform Engineering Team' is not yet in place.
infrastructure
Runbooks and alerting for high-severity risks
5 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: Marketplace Mixed. Each requires documented mitigation before production deployment.
Gap signal: No mitigation strategy is documented for the high-risk nodes in the topology.
Infrastructure Requirements
Elasticsearch
high burdenDistributed full-text search and analytics engine built on Apache Lucene, designed for near-real-time indexing, complex search queries, and log analyt
Managed: Elastic Cloud (Elastic.co), Amazon OpenSearch Service, Elastic Cloud on Kubernetes (ECK)
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 read hotspot signals
Seed 'Read Hotspot Saturation' identifies 3 metrics relevant to hot_partition. Execution preview confirms this risk manifests under modelled load.
Seed 'Read Hotspot Saturation' identifies 3 metrics relevant to hot_partition. Execution preview confirms this risk manifests under modelled load.
Track Hot Partition exposure
Hot Partition has high exposure and affects 1 component. Affects 1 node. (Marketplace Mixed)
Hot Partition has high exposure and affects 1 component. Affects 1 node. (Marketplace Mixed)
Track Cascading Failure exposure
Cascading Failure has high exposure and affects 0 components. Affects 0 nodes
Cascading Failure has high exposure and affects 0 components. Affects 0 nodes
Track Lock Contention exposure
Lock Contention has high exposure and affects 0 components. Affects 0 nodes
Lock Contention has high exposure and affects 0 components. Affects 0 nodes
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
Redis cache miss spike visible in monitoring; PostgreSQL query rate spiking for listing reads despite stable write volum
This signal indicates the architecture is approaching 'Tier 1: Viral Listing Thundering Herd'. Likely bottleneck: Cache TTL expiry on hot listings during peak traffic: all concurrent requests bypass cache simultaneously.
Tier 1: Viral Listing Thundering Herd
Saga compensation events appearing in order event log; checkout p99 > 2s; pg_locks showing contended rows on inventory_r
This signal indicates the architecture is approaching 'Tier 2: Checkout Saga Contention'. Likely bottleneck: Concurrent checkout transactions competing for the same inventory rows; saga timeout thresholds too aggressive.
Tier 2: Checkout Saga Contention
RabbitMQ queue depth > 100k messages; notification delivery latency > 5 minutes; downstream notification provider (SendG
This signal indicates the architecture is approaching 'Tier 3: Notification Queue Backlog'. Likely bottleneck: Notification consumer throughput insufficient for event fanout rate; or downstream provider rate limiting.
Tier 3: Notification Queue Backlog
Readiness Action Plan
Satisfy: Team at 'platform engineering team' maturity level
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Two-Sided Marketplace Platform
Satisfy: Failure mode awareness and runbooks
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Two-Sided Marketplace Platform
Satisfy: Production-grade observability stack
Effort: 1–4 weeks depending on current state · Unblocks: Adoption of Two-Sided Marketplace 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: Hot Partition
Effort: 1–3 weeks · Unblocks: Reduces 'Hot Partition' from blocking adoption
Mitigate risk: Cascading Failure
Effort: 1–3 weeks · Unblocks: Reduces 'Cascading Failure' from blocking adoption
Go Signals
- ✓Team has hands-on experience with all 5 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 Two-Sided Marketplace Platform's documented failure modes.
- ✗No observability baseline exists for the critical components.
- ✗Top risk is unmitigated: 'Hot Partition', do not proceed without addressing this.
Critical Gaps
- This scenario has expert operational complexity, teams without deep production experience will struggle to operate it safely.
Team Requirements
Elasticsearch operations
Required level: proficient
Team can explain Elasticsearch's failure modes, tune configuration parameters under load, and recover from common operational issues.
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
5Recommendations
12Monitor: Hot Partition
risk_monitoringOne partition (a database shard, a Kafka topic partition, a Redis hash slot) receives traffic so far above its peers that it saturates while the others sit idle. Aggregate capacity looks healthy, but the hot partition throttles or lags, and everything routed to it degrades. The cause is skew in how keys map to partitions, and the fix depends on whether the skew is spread across many keys or concentrated in one.
Affects 1 node. (Marketplace Mixed)
Monitor: Cascading Failure
risk_monitoringA failure or degradation in one service causes increased load, held resources, or error propagation in its callers, which in turn degrade their callers, until the failure front propagates through the entire dependency graph and brings down services with no direct dependency on the original failure point.
Affects 0 nodes
Implement: Monitor read hotspot signals
observabilitySeed 'Read Hotspot Saturation' identifies 3 metrics relevant to hot_partition. Execution preview confirms this risk manifests under modelled load.
Metrics to instrument: partition_qps, p99_latency_ms, cache_hit_rate
Monolithic marketplace application with single database → Event-driven marketplace with Kafka + saga-based checkout flow
migration_planningTrigger: Checkout failures from payment provider unavailability causing full transaction rollback and user-facing errors; need for asynchronous notification delivery; listing search performance insufficient from PostgreSQL full-text search. Migrate from 'Monolithic marketplace application with single database' to 'Event-driven marketplace with Kafka + saga-based checkout flow'. Introduce the outbox pattern and Kafka event publishing before the saga orchestration layer. Validate event delivery reliability before building compensating transaction logic on top of it.
Saga implementation requires designing and testing all compensation paths: untested compensation logic fails exactly when it is most needed; Kafka adds operational complexity that small teams may not be ready to operate
PostgreSQL full-text search for listing discovery → Elasticsearch for listing search with CDC-based indexing
migration_planningTrigger: Listing search p99 > 1s; faceted navigation (category + price + location + rating) not supportable in PostgreSQL without full-table scans; ranking algorithm requiring feature vectors that PostgreSQL cannot efficiently support. Migrate from 'PostgreSQL full-text search for listing discovery' to 'Elasticsearch for listing search with CDC-based indexing'. Run the Elasticsearch index in shadow mode (populated but not serving traffic) for 2 weeks before cutting over search traffic. Validate that listing updates propagate within the expected SLA window during the shadow period.
Elasticsearch index must be initially populated from PostgreSQL before CDC takes over: initial sync must complete without data loss; Search index staleness during CDC consumer lag must be explicitly communicated in the search UX
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'Two-Sided Marketplace 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 Two-Sided Marketplace 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: Viral Listing Thundering Herd
scaling_monitoringSignal: Redis cache miss spike visible in monitoring; PostgreSQL query rate spiking for listing reads despite stable write volume; p99 listing API latency > 500ms during traffic spike events
Bottleneck: Cache TTL expiry on hot listings during peak traffic: all concurrent requests bypass cache simultaneously. Evolution: Implement staggered TTL jitter on listing cache entries; use probabilistic early refresh (refresh before TTL expiry when remaining TTL < 20% and request rate is high); implement single-flight/request coalescing at the application layer to collapse concurrent cache misses into a single database read
Scaling Pressure Signals
8Redis cache miss spike visible in monitoring; PostgreSQL query rate spiking for listing reads despite stable write volume; p99 listing API latency > 500ms during traffic spike events
Threshold
Tier 1: Viral Listing Thundering Herd
Likely Bottleneck
Cache TTL expiry on hot listings during peak traffic: all concurrent requests bypass cache simultaneously
Recommended Evolution
Implement staggered TTL jitter on listing cache entries; use probabilistic early refresh (refresh before TTL expiry when remaining TTL < 20% and request rate is high); implement single-flight/request coalescing at the application layer to collapse concurrent cache misses into a single database read
Saga compensation events appearing in order event log; checkout p99 > 2s; pg_locks showing contended rows on inventory_reservations table; idempotency key conflicts increasing in payment service logs
Threshold
Tier 2: Checkout Saga Contention
Likely Bottleneck
Concurrent checkout transactions competing for the same inventory rows; saga timeout thresholds too aggressive
Recommended Evolution
Increase inventory reservation table partition count; tune saga step timeout to 2x the observed p99 for each step under load; implement a per-listing checkout serialization queue to prevent N concurrent sagas competing for the same inventory
RabbitMQ queue depth > 100k messages; notification delivery latency > 5 minutes; downstream notification provider (SendGrid, FCM) rate limit errors in consumer logs; dead-letter queue receiving messages from retry exhaustion
Threshold
Tier 3: Notification Queue Backlog
Likely Bottleneck
Notification consumer throughput insufficient for event fanout rate; or downstream provider rate limiting
Recommended Evolution
Add notification consumer replicas; implement consumer-side rate limiting against downstream provider quotas; tune RabbitMQ prefetch count to prevent consumer overload on recovery; implement dead-letter queue with manual review tooling
Database connection pool exhausted by combination of checkout + search + listing writes all competing for the same PostgreSQL pool; single PostgreSQL primary CPU > 80% sustained; domain boundaries in code becoming unclear as direct table access crosses service lines
Threshold
Tier 4: Domain Service Decomposition Pressure
Likely Bottleneck
Shared PostgreSQL primary unable to serve multiple domain workloads simultaneously without resource contention
Recommended Evolution
Decompose into separate PostgreSQL databases per domain (listings, orders, payments, users) using the database-per-service pattern; each domain has its own connection pool; cross-domain data access goes through events, not direct database queries
Redis cache miss spike visible in monitoring; PostgreSQL query rate spiking for listing reads despite stable write volume; p99 listing API latency > 500ms during traffic spike events
Threshold
Escalation trigger: Cache TTL expiry on hot listings during peak traffic: all concurrent requests bypass cache simultaneously
Likely Bottleneck
Tier 1: Viral Listing Thundering Herd
Recommended Evolution
Monitor: partition_qps, p99_latency_ms, cache_hit_rate
Saga compensation events appearing in order event log; checkout p99 > 2s; pg_locks showing contended rows on inventory_reservations table; idempotency key conflicts increasing in payment service logs
Threshold
Escalation trigger: Concurrent checkout transactions competing for the same inventory rows; saga timeout thresholds too aggressive
Likely Bottleneck
Tier 2: Checkout Saga Contention
Recommended Evolution
Monitor: partition_qps, p99_latency_ms, cache_hit_rate
RabbitMQ queue depth > 100k messages; notification delivery latency > 5 minutes; downstream notification provider (SendGrid, FCM) rate limit errors in consumer logs; dead-letter queue receiving messages from retry exhaustion
Threshold
Escalation trigger: Notification consumer throughput insufficient for event fanout rate; or downstream provider rate limiting
Likely Bottleneck
Tier 3: Notification Queue Backlog
Recommended Evolution
Monitor: partition_qps, p99_latency_ms, cache_hit_rate
Database connection pool exhausted by combination of checkout + search + listing writes all competing for the same PostgreSQL pool; single PostgreSQL primary CPU > 80% sustained; domain boundaries in code becoming unclear as direct table access crosses service lines
Threshold
Escalation trigger: Shared PostgreSQL primary unable to serve multiple domain workloads simultaneously without resource contention
Likely Bottleneck
Tier 4: Domain Service Decomposition Pressure
Recommended Evolution
Monitor: partition_qps, p99_latency_ms, cache_hit_rate
Migration Readiness
12Migration Stages
3Monolithic marketplace application with single database → Event-driven marketplace with Kafka + saga-based checkout flow
infoMigration trigger: Checkout failures from payment provider unavailability causing full transaction rollback and user-facing errors; need for asynchronous notification delivery; listing search performance insufficient from PostgreSQL full-text search
PostgreSQL full-text search for listing discovery → Elasticsearch for listing search with CDC-based indexing
infoMigration trigger: Listing search p99 > 1s; faceted navigation (category + price + location + rating) not supportable in PostgreSQL without full-table scans; ranking algorithm requiring feature vectors that PostgreSQL cannot efficiently support
Monolithic PostgreSQL serving all domain writes → Domain-separated databases with event-based cross-domain data propagation
infoMigration trigger: Domain teams stepping on each other's schema migrations; database resource contention across domains (listing writes vs checkout transactions vs analytics); need to independently scale checkout volume without scaling listing read capacity
Risks
9Saga implementation requires designing and testing all compe
warningSaga implementation requires designing and testing all compensation paths: untested compensation logic fails exactly when it is most needed
Kafka adds operational complexity that small teams may not b
warningKafka adds operational complexity that small teams may not be ready to operate
Elasticsearch index must be initially populated from Postgre
warningElasticsearch index must be initially populated from PostgreSQL before CDC takes over: initial sync must complete without data loss
Search index staleness during CDC consumer lag must be expli
warningSearch index staleness during CDC consumer lag must be explicitly communicated in the search UX
Cross-domain queries that were previously JOIN operations mu
warningCross-domain queries that were previously JOIN operations must become event-driven denormalized data or API calls: significant application refactoring required
Domain event schema contracts must be versioned and maintain
warningDomain event schema contracts must be versioned and maintained: breaking changes require coordinated multi-service deployment
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