Book Seller · Source figure reproductions

Two Architecture Families

The first design discovers prices during order processing. The second continuously ingests seller updates and matches orders against platform inventory state.

Figure A · Worker-based seller polling

Open SVG ↗
Users and sellers use an API gateway; registration and orders persist in MySQL; SQS workers use Redis, a seller gateway, seller APIs, and Stripe.
Source: CombinedOliveTyrannosaurus163 · Staff. Strong at durable intake, explicit seller holds, rate limiting, and idempotency. Reviewers flag all-seller fan-out and author-based queue partitions.

Figure B · Ingested inventory and matching

Open SVG ↗
Seller registration and inventory updates feed Postgres and a book-partitioned stream; Matching Service coordinates inventory, payment, third-party ordering, and notifications.
Source: SunnyCoralWoodpecker578 · Staff. Strong at per-book sequencing, signed updates, and saga structure. Reviewers require one reservation writer and an explicit hold expiry and compensation lifecycle.

Other reviewed figures

Async workersRohitashwa Nigam uses Postgres, an outbox, a hosted queue, multi-step workers, client-side Stripe, seller circuits, and cached offers.
Kafka + OCCDominantScarletBoa987 uses registration, DynamoDB, Kafka, a Book Service, payment processor, per-item ordering, and optimistic concurrency.