= Distributed James Server &mdash; Consistency Model
:navtitle: Consistency Model

:backend-name: cassandra
:backend-name-cap: Cassandra
:server-name: Distributed James Server
:mailet-repository-path-prefix: cassandra
:xref-base: distributed
:data_replication_extend: servers:distributed/architecture/consistency_model_data_replication_extend.adoc

include::partial$architecture/consistency-model.adoc[]

== Denormalization

In Cassandra, data needs to be structured to match the read patterns. To support several conflicting
read patterns, the data needs to be duplicated into different structures. This process is called
denormalization.

While data can be consistent at the table level, some inconsistencies can sneak in at the applicative
level across denormalization tables.

We write to a "table of truth" first, then duplicate the data to denormalization tables.

The {server-name} offers several mechanisms to mitigate these inconsistencies:

- Writes to denormalization tables are retried.
- Some xref:{xref-base}/operate/guide.adoc#_solving_cassandra_inconsistencies[SolveInconsistencies tasks] are exposed and are able to heal a given denormalization table.
They reset the "deduplication tables" content to the "table of truth" content.
- link:https://github.com/apache/james-project/blob/master/src/adr/0042-applicative-read-repairs.md[Read repairs],
when implemented for a given denormalization, enables auto-healing. When an inconsistency is detected, They reset the
"deduplication tables" entry to the "table of truth" entry.
