Modifying an in-progress order without corrupting its total

Alternatives considered

Discarded

Add items through separate changes and rely only on idempotency.

Chosen

Add the items, resolve their prices, and recalculate every active item within a single transaction with retry.

Decision made

Define a single operation to add multiple items to an existing order, resolve their prices when adding them, and recalculate the entire order within a single transactional operation with retry.

Rationale

Idempotency alone doesn't cover two different modifications happening concurrently. Recalculating inside a single operation protects the denormalized total.

Evidence from production

A real case was confirmed of adding items to an order that was already marked ready. The operation defined to resolve it was not yet implemented at the time of this record.

Frequently asked questions

What did Pyae decide about "modifying an in-progress order without corrupting its total"?

Define a single operation to add multiple items to an existing order, resolve their prices when adding them, and recalculate the entire order within a single transactional operation with retry.

Is there production evidence for this decision?

A real case was confirmed of adding items to an order that was already marked ready. The operation defined to resolve it was not yet implemented at the time of this record.

What's a race condition when modifying an order?

It's when two legitimate, concurrent changes to the same order corrupt its calculated total, because each one starts from a state the other has already changed. Pyae confirmed a real case of adding items to an order that was already marked ready.

Why isn't idempotency enough for concurrent modifications?

Idempotency protects against retries of the same request, but it doesn't cover two different changes arriving at the same time. Pyae defines a single transactional operation with retry to handle that case.

How do you recalculate an order's total without corrupting it?

By adding the items, resolving their prices, and recalculating every active item within a single transactional operation with retry, instead of applying each change as an isolated update.