Database Transactions

Treat this as one business action with two different consistency zones:

1. the atomic part: create the order record and reserve inventory
2. the eventual part: publish the event

The key transaction question is whether inventory reservation is part of the same correctness rule as order creation. If an order must never exist without a matching inventory hold, those two writes belong in one short database transaction. If they succeed or fail together, you avoid a mixed atomicity story where the system says “order placed” but stock was never actually reserved.

Inside that transaction, define the exact unit of work clearly:

- insert the order in an initial status such as `pending` or `reserved`
- read the inventory rows that will be decremented or marked reserved
- lock or protect those rows against concurrent buyers
- verify enough stock remains
- apply the reservation
- commit

For concurrency, the main risk is overselling from two requests reading the same available stock and both writing updates. You should make the isolation or locking tradeoff explicit:

- If this is a classic read-modify-write stock decrement, use row locking like `SELECT ... FOR UPDATE` on the inventory rows, or an equivalent optimistic locking/version check if contention is low.
- Default isolation is often enough if paired with explicit row locks.
- Move to `SERIALIZABLE` only if you can name a real anomaly that weaker isolation plus row locks does not prevent, because higher isolation increases retry pressure.

Retry behavior matters too. A transaction can fail because of deadlock, lock timeout, or serialization failure under contention. Retrying is reasonable only if the operation is idempotent. That means the caller should supply a stable request key, or the system should have a business key that prevents duplicate order creation on retry. Without idempotency, a retry can accidentally create two orders or reserve stock twice.

For the event publish, do not hide it directly inside the database transaction if it talks to an external broker or service. External side effects inside the DB transaction create hard failure modes:

- the DB commits but the event is never published
- the event publishes but the DB rolls back
- long network calls keep locks open and increase contention

The usual safer pattern is:

- commit the order + inventory reservation transaction
- write an outbox record in that same transaction describing the event to publish
- have a separate publisher send the outbox event after commit
- make the consumer side idempotent as well, because brokers can redeliver

That gives you one clean atomic transaction for local state, and one eventual-consistency path for messaging.

So the checklist for this flow is:

- Define whether “order created + inventory reserved” is one atomic business action. Usually it is.
- Keep that transaction short and focused.
- Choose a concurrency control strategy for inventory contention: row locks or optimistic version checks.
- Document retry conditions and require idempotency keys.
- Publish through an outbox or equivalent post-commit mechanism, not as an inline external side effect.
- Be explicit about what is immediate (`order`, `inventory hold`) versus eventual (`event delivered`, downstream processing).

If you can state those pieces clearly, your transaction boundary will match the real business rule instead of mixing atomic and eventual work in one fragile flow.