## Data Consistency Defects (Medium)

### Trigger Signals

Start this detection when the following code characteristics appear:
- Cache operations (`cache.set`, `cache.del`, `redis.set`) coexist with database write operations
- Aggregated data (counters, summary values, statistics fields) coexist with detail data
- Read-after-write operations in primary-replica database architecture
- Configuration/rule file loading coexists with runtime usage

### Judgment Process

1. **Identify data synchronization relationships**: `Read` extracts the correspondence between data sources (primary DB/details) and data replicas (cache/aggregates/replica DB)
2. **Check cache synchronization**: For cache + database write operations, `Read` checks:
   - Whether cache is updated/deleted after writing to DB
   - Whether update order is reasonable (write DB then delete cache vs. delete cache then write DB)
   - Whether there is a concurrency window causing stale cache reads
3. **Check aggregated data updates**: For aggregate fields (totalCount, amount, summary), `Read` confirms:
   - Whether aggregated values are updated synchronously after detail changes
   - Whether aggregated values can be repaired through recalculation (reconciliation mechanism)
4. **Check read-write separation**: For immediate read-after-write scenarios, `Read` confirms whether there is forced primary read logic (avoiding reading stale data due to primary-replica lag)
5. **Check configuration hot-reload**: For runtime configurations, `Read` confirms whether there is a reload mechanism after changes

### Evidence Construction

After confirming a defect, the output must include:
- Data source and replica relationship (primary DB <-> cache, details <-> aggregates, primary <-> replica)
- Inconsistency window (which operation causes inconsistency, when it occurs)
- Business impact (consequences of reading stale data: incorrect balance judgment, displaying expired information, rules not taking effect)

### Exclusions

- Scenarios accepting eventual consistency (with clear retry/reconciliation mechanism)
- Read-only caches (no inconsistency from write operations)
- Consistency already guaranteed by data synchronization middleware like Canal/Debezium
