The else case

CAP describes what happens during a network partition. PACELC adds the sentence CAP is missing: and the rest of the time.

The statement

If there is a partition (P), choose between availability (A) and consistency (C).
Else (E), choose between latency (L) and consistency (C).

Daniel Abadi wrote it in 2010 and published it in 2012. The addition is small and decisive: the first half describes a rare condition, and the second half describes every request.

Why the else case is the one that matters

The senior course "System Design: CAP theorem" established that this application has one database node, so it has never had a partition and can't have one.

It makes an else-case decision all the time.

# app/queries/admin/stats_query.rb
Rails.cache.fetch("admin/stats/#{resolved}", expires_in: 5.minutes) do

# app/helpers/catalog/course_helper.rb, used by the roadmap's cached collection render
def card_cache_key(course, progress)
  prog = progress[course.id]
  [ course, I18n.locale, current_user.present?, prog&.percentage, prog&.enrolled ]
end

Those two lines make opposite choices in the same codebase, and neither has anything to do with partitions.

The two choices, measured

The stats query chooses latency. expires_in: 5.minutes says to serve a dashboard that may be five minutes old instead of rebuilding, on every request, a result with twenty-three fields built from aggregate queries. That's EL: latency over consistency, with a stated bound.

The course card chooses consistency. The cache key is [course, I18n.locale, current_user.present?, prog&.percentage, prog&.enrolled], and Rails turns course into a key that contains its updated_at. Editing the course changes the key, so the old fragment is never served again. That's EC: consistency over latency, paid for by rebuilding the fragment after every write.

flowchart TB
  S["Rails.cache.fetch(..., expires_in: 5.minutes)"] --> S1["EL: latency over consistency"]
  S1 --> S2["bounded staleness: up to 5 minutes"]
  C["card_cache_key: [course, I18n.locale, ...]"] --> C1["EC: consistency over latency"]
  C1 --> C2["a write changes the key. never stale, always rebuilt"]
  S1 --> N["neither has anything to do with a partition"]
  C1 --> N

The count

In this application, counted on 2026-09-28:

That's seven else-case decisions and zero partition decisions, which is the ratio PACELC exists to point out.

What CAP could not say

CAP can't see any of those seven. The theorem describes a distributed data store during a partition, and a fragment cache in a single-node Rails application is neither.

Yet the decision has the same structure: serve something that may be out of date and be fast, or check that it's current and be slower. PACELC's contribution is naming that as the same trade-off, so a team thinks about a cache TTL with the care it would give a replica.

That reframing is the whole practical value, and it's why this course isn't a footnote to the previous one.

The question to carry

For any read, in any system, ask:

What is the maximum age of the data this answer may be based on, and what did we pay to make it that fresh?

Five minutes, and twenty-three aggregates saved. Zero, and a rebuilt fragment. Both are answers. The failure is not having one, and that failure is common because nobody thinks of a cache as a consistency decision.

Key takeaways

• PACELC: if partitioned, choose availability or consistency. Else, choose latency or consistency.
• The first half describes a rare condition, and the second describes every request.
• expires_in: 5.minutes is EL with a stated bound. The course card's [course, ...] key is EC, paid for by rebuilding after writes.
• This application makes seven else-case decisions and zero partition decisions.
• The question for any read: what is the maximum age of this answer, and what did we pay for that freshness?