Two Technicians Cannot Both Reserve the Last Kit

Two technicians open the same stock record. Each sees enough parts and submits a reservation. If each program writes a quantity calculated from its earlier screen, one reservation can overwrite the other.

The decision needs to be checked where the change happens. Botie will combine the record version with the stock rule, then apply the update only if that complete condition still holds.

Check identity and revision on one branch, sufficient stock on another, then connect their joint decision to the update.

{
  "accepted": true,
  "record": {
    "id": "seal-kit",
    "version": 5,
    "units": 5
  }
}

The precondition asks whether this is the intended stock record, whether its version still matches, and whether enough units remain. The effect decreases units and increments the version. These are separate pieces even when one database command evaluates them together.

Our local function returns an accepted flag and a record. On rejection it keeps the entire old record. That makes the outcome inspectable without pretending a rejected reservation succeeded.

In the real service, the check and effect must share the database’s atomic write boundary.

The request carries expected_version from the read that informed the technician’s decision. A successful change advances the record’s version. An old request then fails even if its proposed quantity would be legal in isolation.

Every writer participating in this protocol must advance the version consistently. A maintenance script that updates units without doing so can invalidate the assumption. Blindly replacing expected_version with the latest one turns a conflict into an unreviewed new decision.

A version check is useful only when all relevant writes follow its contract.

Python dictionaries let us inspect the components independently. Check the identifier and version, then compare requested units with available units. Combine the booleans before changing a copied dictionary.

The browser runs one function invocation at a time. It demonstrates the state transition and rejection behaviour, but the function itself is not an atomic database write and is not safe as a concurrent inventory service.

The challenge asks for the transition model so we can test what an accepted or rejected command should mean.

current = {"id":"seal-kit", "version":5, "units":5}
proposal = {"id":"seal-kit", "expected_version":4, "amount":3}
version_matches = current["version"] == proposal["expected_version"]
enough_stock = current["units"] >= proposal["amount"]
print(version_matches, enough_stock)
print(version_matches and enough_stock)

False True
False

The server should construct the permitted operation. The caller supplies validated values, not an arbitrary update expression or a dictionary of database operators. Tenant scope comes from authenticated application context and must be checked before issuing the storage command.

Use a service role limited to the necessary table and operations. Attribute-name placeholders and value bindings keep expression structure separate from values; they do not replace authorisation. A partition key containing north cannot prove the requester belongs to north.

The following reference performs a real write only in an explicitly prepared external development table.

import boto3
from botocore.exceptions import ClientError

table = boto3.resource("dynamodb", region_name="us-east-1").Table("maintenance_stock_dev")
try:
    result = table.update_item(
        Key={"id": "seal-kit"},
        UpdateExpression="SET #u = #u - :amount, #v = #v + :one",
        ConditionExpression="#v = :expected AND #u >= :amount",
        ExpressionAttributeNames={"#u":"units", "#v":"version"},
        ExpressionAttributeValues={":amount":3, ":one":1, ":expected":4},
        ReturnValues="ALL_NEW",
    )
    print(result["Attributes"])
except ClientError as error:
    if error.response["Error"]["Code"] == "ConditionalCheckFailedException":
        print("Re-read and reconcile the reservation")
    else:
        raise

If the server applies the update but the response is lost, the client cannot conclude that nothing happened. Repeating an unconditional decrement can reserve twice. Repeating the original versioned request will fail after a successful first application, but that failure alone cannot tell the client whether its own first attempt or another writer changed the record.

A production reservation needs a stable operation identity and a documented receipt or idempotency mechanism, with its scope and retention understood. Reconcile an unknown result before presenting another reservation as a new action.

The exercise has no transport and no persistent receipts. Its accepted flag describes only this local invocation.

A single-item condition can protect that item’s stock. It does not automatically reserve a kit in one record and book an engineer in another as one unit. Multi-item invariants require a supported transaction mechanism or an explicit workflow with compensation and visible partial states.

Test a repeated request, insufficient stock and an incorrect identity. Then test the actual server operation with concurrent callers before relying on it in production.

The next lesson considers operations whose replicas can merge safely after disconnected work.