Skip to main content

​
Overview

Travelbase is strongly consistent for single-resource operations and eventually consistent for derived data such as aggregates, search indexes, and usage metrics. Understanding this distinction will save you from writing unnecessary polling logic — and from missing the cases where it actually matters.

Strong Consistency

Any resource you create or update is immediately readable by its ID on the very next request — on any server, in any region.

Eventual Consistency

Aggregates, list filters, search indexes, and usage counters may lag by up to a few seconds after a write before reflecting the latest state.

​
What Is Consistent When

After a write, always redirect to or reference the resource by ID rather than reloading a list. The list may not yet include the new record — the individual resource always will.

​
Idempotency

All mutating requests (POST, PATCH, DELETE) accept an Idempotency-Key header. Sending the same key twice within 24 hours returns the original response without creating a duplicate or triggering a second side-effect.
Always use idempotency keys for any request that moves money or creates a booking. A network timeout does not mean the request failed — retrying without a key can result in duplicate bookings.

​
Conflicts

When two requests attempt to update the same resource simultaneously, Travelbase uses optimistic concurrency control. Every mutable resource exposes a version field. Pass it on updates — if the version has moved on since you read the record, the request is rejected.
The correct response to a 409 Conflict is always: re-fetch → apply changes → retry.
The version field increments by 1 on every successful mutation. You can use this to detect whether a record changed between two reads without comparing all of its fields.