DEV Community: Tanay Karmarkar

WTH is CAP Theorem Really?

Tanay Karmarkar — Fri, 21 Aug 2026 21:19:11 +0000

CAP tells you what happens during a partition. PACELC tells you what happens the other 99.9% of the time: you trade latency for consistency on every single write, partition or not. If you only design for CAP, you have ignored the trade-off that shapes your p99.

CAP, Precisely Stated In the presence of a network partition (P), a system can provide at most one of: Consistency (C — linearizability) or Availability (A — every non-failed node responds). The theorem is narrower than folklore: it says nothing about normal operation, it compares linearizability against total availability, and it assumes the partition is real. Many "CA systems" in slideware are CA only because the slides omit P.

CP: Refuse to answer on the minority side. etcd, Consul, Spanner, CockroachDB (majority required).
AP: Answer from any replica, reconcile later. Cassandra, DynamoDB, CouchDB (tunable, but AP by default).
In production the partition is not hypothetical — it is a rolling kernel upgrade that holds a rack's switch for 11 seconds, an AZ failure, or a noisy neighbor saturating the NIC. Your "rare partition" happens monthly.

#PACELC: The Trade-Off You Pay Every Day Daniel Abadi's PACELC completes the picture....read more here

WTH is CAP and PACELC? — Tanay Karmarkar

WTH is CAP and PACELC? CAP tells you what happens during a partition. PACELC tells you what you pay the other 99.9% of the time.

portfolio.tanaykarmarkar.com

WTH is PostgreSQL Transaction ID Wraparound?

Tanay Karmarkar — Mon, 17 Aug 2026 05:40:06 +0000

One of the most abrupt production outages you can experience in PostgreSQL doesn’t come from a hardware failure—it comes from a mathematical boundary.

PostgreSQL handles Multi-Version Concurrency Control (MVCC) using a 32-bit Transaction ID (XID) space. Because there are only ~4.2 billion available IDs, the database treats this space as a circular ring: roughly 2.14 billion transactions represent the "past" (visible data), while the rest represent the "future" (invisible data).

The danger of XID wraparound occurs when your global transaction counter advances too rapidly without "freezing" older rows. If an unfrozen row falls out of that 2.14 billion transaction safe window, its ID mathematically flips into the future. When this happens, completely valid production data suddenly becomes invisible to your queries.

To prevent this silent data corruption, PostgreSQL will forcefully reject new write operations and halt database operations once it gets within 11 million transactions of wraparound.

Usually, Autovacuum hums along in the background to freeze old rows and safely advance the window. However, silent blockers like abandoned logical replication slots, orphaned prepared transactions, or even just a single uncommitted long-running query can quietly stall Autovacuum until it's too late.

For a deeper look at the implementation details, including the exact SQL queries to monitor datfrozenxid age, emergency recovery steps, and an interactive simulation of the XID ring, the full breakdown is here:

WTH is PostgreSQL Transaction ID Wraparound? — Tanay Karmarkar

WTH is PostgreSQL Transaction ID Wraparound? 32-bit XIDs will wrap; autovacuum freeze and monitoring prevent forced shutdown.

portfolio.tanaykarmarkar.com

So…#WTH is State Machine Replication?

Tanay Karmarkar — Sun, 16 Aug 2026 06:05:02 +0000

Every replicated database, Kafka partition, and Raft cluster relies on one rule: if deterministic replicas start identical and apply identical commands in an identical order, they stay identical.
Violate the order by one message, and you’ve built two different databases.

In my blog, I learnt and then broke down the mechanics of State Machine Replication (SMR). I cover:

-> The Deterministic Primitive
-> The Replicated Log
-> Exactly-Once Apply

WTH is State Machine Replication? — Tanay Karmarkar

WTH is State Machine Replication? Deterministic replicas must apply identical commands in identical order.

portfolio.tanaykarmarkar.com