Maintained or cached count counters
Parent: Total count strategies for paginated UIs · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Maintained or cached count counters. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- An atomic increment is not automatically safe to retry: AWS documents ambiguous service failures that can happen before or after a counter update, so retrying can overapply and declining a retry can underapply. Exact counter designs need an appropriate deduplication or transactional protocol. (low confidence) [source]
How it works
- A maintained counter stores a precomputed total and updates it when contributing records change, replacing repeated count computation with a stored-value read. This shifts work from UI reads to counter maintenance and is especially useful when reads greatly outnumber writes. (high confidence) [source]
- A historical counter_culture 2.1.4 / Rails 5.2.2 reproduction shows a conditional counter decrementing incorrectly when its predicate reads an associated object; the author recommends basing that predicate on the counted object’s own attributes. This is historical evidence, not verification of a current-version defect. (low confidence) [source]
- Duplicating a total in separately cached page responses can show inconsistent totals when navigating between pages. Codemzy demonstrates this and proposes separating count metadata in the client cache and invalidating other pages when the total changes; this is an implementation example, not a guarantee of database snapshot consistency. (low confidence) [source]
Problems, failure modes and limitations
- Inference for filtered pagination: use a counter whose membership predicate matches the displayed dataset. A simple association total cannot substitute for a conditional total; counter_culture explicitly supports conditional counters that include only qualifying records. (medium confidence) [source]
- The counter_culture project documents deferring counter updates until after commit as a way to address deadlocks, explicitly warning that this gives up transactional guarantees for those updates. (low confidence) (verified as of 2026-10-30) [source]
Comparisons and alternatives
- Mongoid documents counter_cache as a parent-model field storing the number of associated objects. This supplies an association-scoped count, rather than a general total for arbitrary UI filters. (low confidence) [source]
Facts and statements
- A stored total can be refreshed on source-data writes or by a periodic job. Periodic refresh does not guarantee an exact current total; a UI using that strategy must tolerate stale counts. (high confidence) [source]
- Counter caches need initialization from existing records and a way to repair drift. Rails documents stale counters and reset_counters; counter_culture documents backfilling from primary data and recommends periodic reconciliation to detect incorrect cached values. (high confidence) [source]
- A hot shared counter can become a write bottleneck: competing updates serialize or retry, and counter-cache transactions can deadlock. A fast count read therefore does not imply a cheap overall workload. (high confidence) [source]
- PlanetScale documents spreading increments across randomly selected counter slots and obtaining the total by summing those slots. This reduces contention on any one row but adds a rollup read or a separately refreshed aggregate. (medium confidence) [source]
- Atomic increment alone does not ensure correct counting across ambiguous failures. AWS describes DynamoDB failures occurring before or after an increment, making a blind retry capable of applying an update twice; its marker-item transaction pattern records a unique operation token to make retries idempotent. (low confidence) [source]
- Precomputed counts and external caches introduce maintenance work: application logic must propagate source-data changes, while cached query results require invalidation or replacement as records change. (medium confidence) [source]
- Rails documents counter_cache: { active: false } for rollout: keep maintaining the counter during child creation/removal while reads continue using database results until backfill has completed. (low confidence) (verified as of 2026-10-30) [source]
Children
- Counter initialization and reconciliation (frontier)
- Idempotent counter maintenance (frontier)
- Sharded or slotted counters (frontier)
- Predicate-specific counters (frontier)
- Count-cache freshness and invalidation (frontier)
Frontier under this node: Count-cache freshness and invalidation, Counter initialization and reconciliation, Idempotent counter maintenance, Predicate-specific counters, Sharded or slotted counters