Transactions & consistency¶
fdyno runs every operation on FoundationDB's strictly serializable ACID transactions. This determines its consistency guarantees, several of which are stricter than DynamoDB's. For the formal treatment (the model fdyno provides, the anomalies it rules out, and its boundaries) see the Consistency model reference.
One transaction per request¶
Each DynamoDB operation runs inside a single FoundationDB transaction. For a write, that transaction covers, atomically:
- the base item,
- every affected GSI and LSI entry,
- the change-stream (CDC) record, if the table has a stream,
- and, for
TransactWriteItems, the idempotency token.
Either all of these commit together or none do. There is no intermediate state in which an index, a stream record, or a base item is out of sync.
Synchronous secondary indexes¶
DynamoDB global secondary indexes are eventually consistent: a write to a base table propagates to its GSIs asynchronously, so a query against a GSI can briefly miss a just-written item. fdyno maintains all indexes synchronously in the write transaction, so:
- an index reflects a write the instant that write commits,
- a multi-instance deployment never sees an index lag a base write,
- and a process restart cannot leave indexes partially updated.
Indexes are part of the durable write
Index maintenance is never an in-memory or background queue. Index entries are part of the durable, atomic write. A bounded, resumable backfill is used only to populate an index over existing items when that index is first created.
Idempotent transactions¶
TransactWriteItems accepts a ClientRequestToken. fdyno persists the token in
FoundationDB inside the same transaction as the writes it guards. A replay of
the same token is recognized atomically and becomes a no-op, so a client that
retries after a network failure cannot double-apply a transaction, and that
guarantee survives process restarts because the token is durable, not in memory.
Consistency model¶
| Operation | fdyno | DynamoDB |
|---|---|---|
GetItem (strongly consistent) |
Reads latest committed value | Same |
GetItem (eventually consistent) |
Reads latest committed value | May read slightly stale |
| Query/Scan on a base table | Strongly consistent | Strongly consistent option |
| Query/Scan on a GSI | Strongly consistent | Eventually consistent |
TransactWriteItems |
Serializable, idempotent | Serializable, idempotent |
Because FoundationDB reads are snapshot-isolated and writes are serializable, every
fdyno read returns the latest committed state. fdyno has no separate
eventually-consistent read mode; an eventually-consistent GetItem returns the
same latest value as a strongly-consistent one.
The durable-state invariant¶
The architecture rests on one rule:
All externally visible durable state lives in FoundationDB. A server process holds no durable state.
This is what makes losing a process safe. Concretely, after a restart:
- TTL configuration survives, so item expiry continues correctly after a restart,
- tags and resource policies survive,
- idempotency tokens survive, so a replayed transaction is still a no-op,
- and table schema, items, indexes, streams, and backups are all intact.
Every feature is designed as if multiple fdyno processes share one FoundationDB cluster, because they can.