Marketplace, Dispatch, and Logistics System Design Questions

I would treat this as a live incident and optimize for containment first.

Triage and containment

• Confirm the blast radius: which markets, listing types, and booking paths are affected.
• Check recent deploys, feature flags, and error logs to correlate the spike with the release.
• If double-booking is possible, I would immediately disable the risky feature path or roll back the release if the regression is broad and I cannot prove a safe workaround.

Temporary safeguards

• Tighten reservation locking or make the booking endpoint reject ambiguous requests.
• Add a short-lived guard such as a stricter hold check, lower retry pressure, or a circuit breaker around the new code path.
• If needed, degrade nonessential functionality, but never relax correctness on booking writes.

How I decide

• Roll back when the incident is clearly tied to the release and the fix is not fully understood.
• Disable a feature flag when the issue is isolated to one capability and the rest of the release is safe.
• Add safeguards when rollback is risky, but I still need time to investigate.

While investigating
I would verify idempotency, locking, and race conditions around holds and confirms, then communicate status and ETA to support and product. The main goal is to stop customer harm quickly, then restore the feature safely.

I would use strong consistency where correctness has immediate user impact, and eventual consistency where the system can tolerate brief lag.

Strong consistency is best for

• Creating a hold on inventory
• Confirming or cancelling a reservation
• Charging a payment or finalizing a booking state

These are write paths where two users cannot both succeed for the same slot. If the system is inconsistent here, double-booking or double-charging can happen.

Eventual consistency is acceptable for

• Search indexes
• Listing pages and cached availability summaries
• Notifications, analytics, and recommendations

A short delay in these areas usually affects freshness, not correctness. That is an acceptable trade-off because it improves scalability and lowers latency.

Trade-off

• Strong consistency gives safer correctness, but usually costs more in latency and coordination.
• Eventual consistency scales better and keeps the product fast, but the UI must tolerate stale reads.

For a marketplace, I would keep the booking commit path strict and transactional, while letting discovery and reporting flow through asynchronously updated systems.

I would make the payment flow stateful, idempotent, and fully auditable.

Flow

• When a reservation is confirmed, create a payment record with a unique idempotency key.
• Send the processor an authorization or capture request only once for that key.
• Store the processor transaction ID and current state in the database.
• Use webhooks as the source of truth for asynchronous confirmation, not the client response alone.

Reliability controls

• Retries must reuse the same idempotency key so a repeated request cannot double charge.
• Webhooks should be signature-verified and deduplicated by event ID.
• A background reconciler should compare local state with processor state for any stuck or missing updates.

Auditability

• Keep an immutable payment event log with request, response, webhook, and state transition timestamps.
• Record who initiated the action, which reservation it belongs to, and which processor object was used.

State model
Pending -> Authorized -> Captured -> Settled, with failure and refund states handled explicitly.

The important principle is that the database should track the business transaction, while the payment provider handles money movement. That separation makes retries safe and incident review much easier.

I would start by measuring where the latency and errors actually come from before changing architecture.

First pass analysis

• Break down p95 latency by search results, availability checks, and booking submissions.
• Inspect CPU, DB time, lock waits, slow queries, GC pauses, and downstream call latency.
• Check whether spikes are read-heavy, write-heavy, or caused by lock contention.

Decision order

1. Scale horizontally if the monolith is mostly CPU-bound or stateless enough to run more replicas.
2. Add read replicas and caching if search and availability are dominated by reads.
3. Change the data model if queries are slow because the schema is not shaped for the access pattern.
4. Split services only after identifying stable boundaries, such as search, availability, and booking.

My bias
For hot paths, I would usually fix data access first: better indexes, denormalized read models, and narrower queries. That often gives the fastest win with the least operational risk.

I would split services when the monolith creates independent scaling or deployment pain, especially if search traffic and booking writes have very different needs. The goal is to remove the biggest bottleneck first, not to decompose for its own sake.

I would use events as the contract between services, with each service owning its data and reacting asynchronously.

Publish / consume examples

• Booking service publishes BookingCreated, BookingConfirmed, BookingCancelled.
• Availability service consumes booking events and publishes InventoryHeld or InventoryReleased.
• Payment service consumes BookingConfirmed and publishes PaymentAuthorized or PaymentFailed.
• Search service consumes listing and availability changes to refresh indexes.
• Notification service consumes booking and payment events to send emails or push messages.
• Analytics service consumes the same events for reporting.

Reliability

• Use the outbox pattern so database writes and event publishing stay consistent.
• Make consumers idempotent by tracking event IDs or natural business keys.
• Handle out-of-order delivery by designing events as state transitions, not fragile assumptions about sequence.
• Retry transient failures with backoff, and send poison messages to a dead-letter queue after repeated failures.

Why this works
It decouples services and improves scale, while keeping each one simple. The trade-off is eventual consistency, so the booking UI must be designed to show pending states when downstream systems have not caught up yet.