Skip to content

fdyno and FoundationDB test responsibilities

fdyno translates DynamoDB requests into FoundationDB transactions. fdyno tests the translation. FoundationDB provides transaction isolation, atomic commit, replication, and recovery.

fdyno responsibilities

fdyno must:

  • encode DynamoDB tables, keys, items, and indexes into ordered FoundationDB keys;
  • evaluate conditions and expressions with DynamoDB behavior;
  • write a base item, index entries, a stream record, and an idempotency token in the correct transaction;
  • add the correct read and write conflict ranges; and
  • return DynamoDB-compatible responses and errors.

The conformance suites test these behaviors through AWS SDK clients. They do not test FoundationDB's internal replication or recovery.

FoundationDB responsibilities

FoundationDB must:

  • provide strict-serializable transactions;
  • commit all transaction writes or none of them;
  • replicate committed data according to the cluster configuration; and
  • recover after supported process, machine, disk, and network failures.

fdyno does not implement a second consensus, replication, or recovery system.

Deterministic simulation

FoundationDB can run a complete cluster in one process as a discrete-event simulation. A pseudo-random seed controls the simulated network, disks, clocks, failures, and task scheduling.

The same seed reproduces the same execution. FoundationDB developers can replay a failure instead of treating it as a timing-dependent test failure.

The simulator can inject:

  • network delay, reordering, and partitions;
  • process and machine restarts;
  • disk delay, partial writes, and corruption;
  • clock changes; and
  • rare legal execution paths in the database code.

FoundationDB calls the last mechanism Buggify. It increases the frequency of unusual execution paths so tests can reach them.

Simulation checks FoundationDB's transaction and durability rules across these events. It is FoundationDB evidence. It is not direct evidence for fdyno's request mapping.

Evidence boundary

fdyno's correctness claim has two parts:

  1. fdyno maps tested DynamoDB behavior to the correct FoundationDB transactions.
  2. FoundationDB enforces its documented transaction guarantees.

The fdyno conformance suites test the first part. FoundationDB's own tests and documentation support the second part. Neither source proves behavior that it does not exercise.

fdyno does not currently publish Jepsen or Elle histories for the combined system. See Consistency, Guarantees, and Conformance testing for the exact claims and gaps.

Sources

  • FoundationDB documentation
  • Will Wilson, Testing Distributed Systems with Deterministic Simulation in Apple's FoundationDB, Strange Loop 2014
  • Jingyu Zhou et al., FoundationDB: A Distributed Unbundled Transactional Key Value Store, SIGMOD 2021