Data integrity keeps information accurate, consistent, complete, and trustworthy from creation through deletion or archiving. Across services, databases, and environments, it means data remains uncorrupted and in sync with the source of truth. section 13.3.1
Distributed systems do not guarantee consistency by default. Silent data drift can leave records misaligned across services or databases, so monitoring and enforcement must detect mismatches, missing relationships, and delayed synchronization before they become business problems. section 13.3
Use complementary checks to investigate integrity failures:
- Calculate a checksum when data is generated or transmitted, then recompute it after storage or receipt. Matching values suggest intact data; differences indicate likely corruption or alteration. section 13.3.1
- Prefer CRC32 or Adler-32 for fast detection of accidental errors such as bit flips, incomplete writes, and faulty network transmissions; do not treat checksums as protection against intentional tampering. section 13.3.1
- Run reconciliation jobs that compare expected and actual state across services, queues, storage layers, replicas, caches, or integration points. section 13.3 section 13.5
- Correlate database state, application intent, and event logs to distinguish what should have happened from what actually happened. section 13.5
File verification
A download site publishes file.exe with CRC32 checksum A12F3B4C. Recalculating the received file's checksum and comparing the values reveals whether storage or transmission likely corrupted it. section 13.3.1
Figure 13.7 A consistency problem. Account balances do not reflect the correct amounts of money.
Use the account-balance consistency figure to trace how incorrect state can become visible as a distributed-system failure. section 13.3
