# Ankit Rana | Mechanical Sympathy Engineering logs on distributed systems, database internals, CPU and memory behaviour, and AI infrastructure by Ankit Rana, Senior Software Engineer at Walmart Global Tech. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Local and distributed cache coherence: stale data caused by missed invalidation messages DevFeed: [Local and distributed cache coherence: stale data caused by missed invalidation messages]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-17T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Caching](), [Redis](), [data](), [Network]() Tags: [cache](), [cache-coherence](), [caching](), [consistency](), [data](), [distributed-cache](), [distributed-systems](), [jvm](), [network](), [redis](), [ttl]() ### AI overview The article explains that adding an in-process cache in front of a distributed cache can improve latency but creates independently stale copies across service instances. It focuses on Redis pub/sub invalidation, which provides no persistence, acknowledgement, retry, or replay, allowing instances to miss invalidation messages and serve stale data until their TTL expires. ### Source excerpt An in-process cache in front of a distributed cache removes a network hop and adds one independent copy of the data per instance, each of which can be stale on its own schedule. Invalidation is normally broadcast over pub/sub, which is fire and forget, so any instance that is restarting, garbage collecting or briefly disconnected simply misses the message and serves stale data until its TTL expires. That TTL is not a performance setting, it is the maximum duration of incorrectness. ## Why your Redis is slow: it is single threaded and you sent it KEYS DevFeed: [Why your Redis is slow: it is single threaded and you sent it KEYS]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-15T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Redis](), [Latency](), [Concurrency]() Tags: [blocking](), [caching](), [command](), [latency](), [observability](), [performance](), [redis](), [single-threaded]() ### AI overview The article explains that Redis executes commands one at a time on a single thread, so expensive commands can block every client and cause latency spikes across all operations. It identifies KEYS as a key offender and also discusses large DEL operations, unbounded LRANGE, SMEMBERS on large sets, and FLUSHALL. Redis 6 threaded I/O helps with socket handling but does not change single-threaded command execution. ### Source excerpt Redis executes commands one at a time on a single thread, so any command that takes 200ms makes every other client wait 200ms regardless of how trivial their request was. KEYS scans the entire keyspace and is the obvious offender, but DEL on a large collection, unbounded LRANGE, SMEMBERS on a big set and FLUSHALL are all linear in the size of the data and block identically. The tell is a latency spike across all operations at once while CPU and network look normal. ## Cache invalidation is a distributed systems problem DevFeed: [Cache invalidation is a distributed systems problem]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Cache](), [Caching](), [distributed-systems]() Tags: [cache](), [cache-invalidation](), [caching](), [consistency](), [distributed](), [distributed-systems](), [ordering](), [race-conditions](), [redis](), [ttl]() ### AI overview Cache invalidation coordinates updates between a database and a cache without a shared transaction. The article explains how operation ordering can let a concurrent reader repopulate stale data and recommends writing to the database before invalidating the cache, followed by a second invalidation to close the remaining race. ### Source excerpt A cache and a database are two stores that must agree, which makes every invalidation a distributed transaction without a coordinator. The ordering matters more than the mechanism: invalidating before the database write leaves a window where a concurrent reader repopulates the cache with the old value and it stays wrong until the TTL expires. Deleting the key rather than writing the new value removes a whole class of ordering bug, because two concurrent deletes commute and two concurrent writes do not. ## Choosing among write-through, write-behind, and write-around caching strategies DevFeed: [Choosing among write-through, write-behind, and write-around caching strategies]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-11T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Caching](), [Databases](), [Redis](), [consistency](), [Latency]() Tags: [cache](), [caching](), [consistency](), [database](), [latency](), [orders](), [postgres](), [redis](), [strategies](), [system-design](), [write](), [write-behind](), [write-through]() ### AI overview This article compares write-through, write-behind, and write-around caching strategies. It explains their trade-offs among database latency, cache hit rates, consistency, and the risk of losing acknowledged writes when a process fails. ### Source excerpt The three write strategies differ in what happens between the cache write and the database write, and that gap is where correctness lives. Write-through updates both before acknowledging, so it is safe and pays the full database latency. Write-behind acknowledges after the cache write and flushes later, which is fast and can lose acknowledged writes if the process dies. Write-around skips the cache entirely on write, which avoids caching data nobody reads and costs a miss on the next read. ## Negative caching protects databases from repeated lookups for nonexistent keys DevFeed: [Negative caching protects databases from repeated lookups for nonexistent keys]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-09T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Caching](), [Cache](), [Database](), [Security](), [Latency]() Tags: [cache](), [cache-penetration](), [caching](), [database](), [negative-caching](), [protection](), [redis](), [reliability](), [security](), [ttl]() ### AI overview Negative caching prevents repeated database queries for nonexistent keys by storing a distinguishable marker for negative results. The article explains how partner integrations, scrapers, stale clients, migrations, or attackers can exploit this gap and recommends using a shorter TTL for negative entries. ### Source excerpt A cache that stores only found values gives you no protection against lookups for things that do not exist, and a miss on a nonexistent key costs the full origin query every single time. If the key is user supplied, an attacker can generate unlimited unique misses and bypass the cache entirely, which is cache penetration. Caching the negative result fixes it, with a shorter TTL than positive entries because a value appearing is a much more likely event than one disappearing. ## How Fixed Intervals Synchronize Distributed Clients and How Jitter Helps DevFeed: [How Fixed Intervals Synchronize Distributed Clients and How Jitter Helps]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-07T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [reliability](), [distributed-systems](), [systems](), [Network](), [Cache](), [Redis]() Tags: [aws](), [cache](), [code](), [distributed-systems](), [jitter](), [network](), [reliability](), [resilience](), [retries](), [thundering-herd]() ### AI overview Fixed retry intervals, TTLs, restarts, reconnects, and other recurring events can cause independent clients in distributed systems to synchronize, producing repeated load spikes. Adding randomness, or jitter, helps break that alignment; the article cites AWS measurements indicating that full jitter improves total work and completion time under contention. ### Source excerpt Distributed systems synchronise themselves without being told to: every client that retries on a fixed interval, restarts after a deploy, or reconnects after a network blip ends up firing at the same moment as every other client. The resulting spike is a self-inflicted denial of service that no single component is responsible for. Adding randomness to any repeating interval breaks the alignment, and it is usually one line of code against a failure mode that otherwise requires capacity you never needed. ## Cache stampede: how one expired key takes down the database DevFeed: [Cache stampede: how one expired key takes down the database]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-05T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Cache](), [Caching](), [Database](), [consistent hashing](), [Redis]() Tags: [cache-stampede](), [caching](), [connection-pool](), [consistent-hashing](), [distributed-systems](), [jitter](), [query](), [redis](), [reliability](), [thundering-herd](), [traffic](), [ttl]() ### AI overview This article explains how a cache stampede occurs when a hot key expires and many requests simultaneously recompute the same value against the database. It recommends TTL jitter to prevent synchronized expirations and request coalescing so only one caller recomputes while others wait or serve stale data. It also discusses cache warming and consistent hashing for broader cache-failure scenarios. ### Source excerpt A cache TTL is a scheduled simultaneous failure: every request being served from one key misses at the same instant and goes to the origin together. If the recompute takes two seconds, every request arriving during those two seconds also misses, so the pileup grows faster than it drains. Jitter on the TTL stops keys expiring in lockstep, and request coalescing so only one caller recomputes while the rest wait or serve stale is what stops a single expensive key from saturating the database. ## JDBC batching can still issue one round trip per row unless driver statement rewriting is enabled DevFeed: [JDBC batching can still issue one round trip per row unless driver statement rewriting is enabled]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-03T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Databases](), [Latency](), [client](), [Code]() Tags: [batching](), [bulk-load](), [client](), [cost](), [database](), [database-performance](), [durability](), [jdbc](), [latency](), [mysql](), [postgresql](), [server](), [sql]() ### AI overview For small database writes, network round trips and transaction overhead can dominate the actual insert work. The article explains that JDBC batching may accept rows into a client-side batch while still sending separate statements unless driver-side statement rewriting is enabled, and that autocommit adds a transaction and durability barrier per row. ### Source excerpt For small writes the per-statement overhead dominates the actual work, so throughput is set by round trips rather than by the database. JDBC batching is the usual fix and it silently does nothing on the wire unless the driver is told to rewrite the statements, so addBatch can look correct while still issuing one round trip per row. Autocommit compounds it by turning every row into its own transaction and its own durability barrier, which is the difference between one fsync and a hundred thousand. ## When JSONB columns create schema, consistency, and performance problems DevFeed: [When JSONB columns create schema, consistency, and performance problems]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-01T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [data](), [Structured-data](), [JSON]() Tags: [data-modelling](), [indexing](), [jsonb](), [migration](), [outage](), [postgres](), [postgresql](), [query](), [schema](), [schema-design](), [toast]() ### AI overview The article explains why using JSONB to avoid recurring migrations can create hidden schema and data-consistency problems. It discusses runtime failures from inconsistent keys and types, difficulty identifying dependencies across consumers, and the storage and update costs of large PostgreSQL JSONB documents. ### Source excerpt JSONB is a good fit for genuinely open-ended data and a poor one for schema you did not want to commit to yet. Without a schema there is no NOT NULL, no type, no foreign key and no way to know which keys are load bearing, so every read becomes a parse and a cast that can fail at runtime. Large documents are stored out of line and compressed, which means reading one key can require fetching and decompressing the whole document, and updating one key rewrites all of it. ## Foreign keys are not overhead, and the thing you measured was a missing index DevFeed: [Foreign keys are not overhead, and the thing you measured was a missing index]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-30T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Database](), [integrity]() Tags: [database](), [database-performance](), [foreign-keys](), [indexing](), [integrity](), [overhead](), [postgres](), [postgresql](), [referential-integrity](), [schema-design]() ### AI overview The article explains that the measured cost of a slow parent delete is usually caused by a missing index on the child table's foreign-key column, not by foreign-key checking itself. It argues that dropping the constraint merely moves referential-integrity enforcement into application code and can allow orphaned records. ### Source excerpt A foreign key check is an index lookup against a primary key that is almost certainly already in cache, which is close to the cheapest thing a database does. The expensive case people measure is a parent delete with no index on the child's referencing column, which forces a full scan of the child table per deleted row, and that is a missing index rather than a cost of the constraint. Dropping the key does not remove the work, it moves the integrity guarantee into application code where nothing reports when it stops holding. ## Detecting Replica Lag That Breaks Read-Your-Writes Consistency DevFeed: [Detecting Replica Lag That Breaks Read-Your-Writes Consistency]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-28T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Replication](), [Routing (disambiguation)]() Tags: [checkout](), [consistency](), [lag](), [metric](), [observability](), [postgresql](), [primary](), [read-replica](), [read-replicas](), [replica-lag](), [replication](), [routing]() ### AI overview This article explains how read replicas can break read-your-writes behavior when applications do not route related reads to the primary or wait for replication. It compares byte lag with time lag, explains why idle systems can hide failures, and discusses replay delays caused by write bursts and long-running replica queries. ### Source excerpt Byte lag between primary and replica reads zero on an idle primary even when replication is completely stuck, so the metric that looks healthiest is the one that hides the failure. Time lag measured from the last replayed transaction is the signal that stays honest. Adding a read replica silently removes read-your-writes, which means any flow that writes and then reads back needs either primary routing or an explicit wait for the replica to reach that write's log position. ## ADD COLUMN is not always free, and the lock queue is what takes you down DevFeed: [ADD COLUMN is not always free, and the lock queue is what takes you down]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-26T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [PostgreSQL](), [incident](), [Query (disambiguation)](), [migration](), [MySQL]() Tags: [ddl](), [incident](), [locking](), [migration](), [migrations](), [mysql](), [postgresql](), [query](), [queues](), [schema-design](), [timeout]() ### AI overview Adding a nullable column can cause an outage even when the schema change itself is nearly instantaneous. In PostgreSQL, ALTER TABLE may wait for a long-running query, and subsequent queries can queue behind the waiting lock request. Setting a short lock_timeout and retrying can prevent the migration from taking down the table. ### Source excerpt Modern PostgreSQL adds a column with a default as a metadata change, so the table is never rewritten and the migration itself is instant. The outage comes from lock acquisition instead: ALTER TABLE needs an ACCESS EXCLUSIVE lock, and while it waits behind one long-running query, every subsequent query queues behind the waiting ALTER because the lock queue is ordered. Setting lock_timeout to a couple of seconds and retrying converts that from an outage into a no-op. ## Connection pool sizing is a queueing theory problem, not a tuning knob DevFeed: [Connection pool sizing is a queueing theory problem, not a tuning knob]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-22T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [connection pool](), [queueing theory](), [Latency](), [Database](), [Concurrency]() Tags: [capacity-planning](), [concurrency](), [connection-pool](), [cpu](), [database](), [database-performance](), [hikaricp](), [inference](), [latency](), [network](), [postgresql](), [query](), [queueing-theory]() ### AI overview This article explains how to size a connection pool using Little's law: concurrency equals throughput multiplied by connection holding time. It argues that increasing the pool beyond the database's parallel execution capacity can move the queue, increase latency, and leave throughput flat. It also identifies excessive holding time from network round trips, N+1 queries, long transactions, and model inference calls as common causes of pool exhaustion. ### Source excerpt Pool size follows from Little's law: concurrency equals throughput multiplied by holding time, so 500 requests per second each holding a connection for 20ms needs ten connections rather than a round number someone picked. Past the point where the database can execute requests in parallel, adding connections moves the queue rather than removing it, and latency grows while throughput stays flat. The number that actually reaches the database is the pool size multiplied by the instance count, which is usually the number nobody has calculated. ## Soft deletes affect database constraints, indexes, and application queries DevFeed: [Soft deletes affect database constraints, indexes, and application queries]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-20T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [data-processing](), [Database](), [MySQL]() Tags: [data-modelling](), [database-design](), [foreign-keys](), [indexes](), [indexing](), [mysql](), [orm](), [postgresql](), [predicate](), [schema](), [schema-design](), [soft-delete]() ### AI overview The article explains how soft deletion affects database design beyond adding a deleted_at column. It discusses duplicate-key failures, foreign-key behavior, queries that may return deleted rows, and index inefficiency, noting that PostgreSQL partial indexes help while MySQL requires a workaround. ### Source excerpt A deleted_at column turns every future query into a conditional one, and the cost is not the extra predicate. Unique constraints stop working because the deleted row still occupies the key, foreign keys start pointing at rows the application considers gone, and any query written by someone who does not know about the column silently returns deleted data. Soft delete is a data lifecycle decision, and treating it as a boolean column is what makes it expensive. ## Covering Indexes and Index-Only Scans in PostgreSQL DevFeed: [Covering Indexes and Index-Only Scans in PostgreSQL]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [PostgreSQL](), [Query (disambiguation)](), [data]() Tags: [b-tree](), [cache](), [covering](), [covering-index](), [database-performance](), [explain](), [heap](), [indexes](), [indexing](), [innodb](), [pages](), [postgresql](), [query](), [storage](), [vacuum]() ### AI overview This tutorial explains why a normal index scan may still be slow: after finding matching entries, the database follows a pointer into the table for each row. Covering indexes store the selected columns in the index and can avoid those heap reads. In PostgreSQL, index-only scans also depend on the visibility map marking pages all-visible, while SELECT * prevents the technique from being fully effective. ### Source excerpt A normal index scan finds matching rows and then follows a pointer into the table for every one of them, which is a random read per row. A covering index stores the columns the query selects, so the engine answers entirely from the index and skips those reads. In PostgreSQL this only works when the visibility map marks the pages all-visible, so an unvacuumed table will report Heap Fetches in EXPLAIN and give back most of the gain. SELECT star defeats the technique completely. ## Why your index is not being used, and why the planner is usually right DevFeed: [Why your index is not being used, and why the planner is usually right]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Query (disambiguation)](), [MySQL](), [bug]() Tags: [bug](), [cardinality](), [database-performance](), [explain](), [function](), [indexes](), [indexing](), [mysql](), [postgresql](), [predicate](), [query](), [query-planner]() ### AI overview This tutorial explains why database indexes may not be used even when they exist. It focuses on inaccurate cardinality estimates caused by stale statistics, predicates that prevent index matching, implicit casts, and cases where sequential scans are the cheaper choice. ### Source excerpt An unused index is almost never a planner bug. It is usually a predicate the planner cannot match to the index, such as a function or an implicit cast applied to the column, or a cardinality estimate that is wrong because statistics are stale. When the estimate is right and the planner still refuses, it is often correct: past a few percent of the table, random access through an index costs more than reading the table sequentially. The diagnostic that matters is the gap between estimated and actual rows in EXPLAIN ANALYZE. ## How fsync affects data durability, latency, and group commit DevFeed: [How fsync affects data durability, latency, and group commit]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-14T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [data](), [Latency](), [NVMe](), [Replication]() Tags: [databases](), [durability](), [flush](), [fsync](), [postgresql](), [replication](), [ssd](), [stack](), [storage]() ### AI overview This article explains that a successful write() may leave data only in the kernel page cache, so a power loss can destroy it. It describes fsync as the operation that pushes data to the device, discusses its latency cost, and explains how group commit amortizes the synchronization barrier. It also distinguishes disk durability from replication across failure domains. ### Source excerpt A successful write() only copies your data into the kernel page cache, where a power loss destroys it. Only fsync pushes it to the device, and because fsync is a barrier rather than a write, a system that syncs once per commit is capped at roughly one divided by the fsync latency, no matter how fast the rest of the stack is. Group commit exists to amortise that barrier, and replication solves a different failure domain than fsync does, which is why acks=all does not mean the data is on any disk. ## Why CRUD APIs Stop Teaching New Lessons After Basic Production Problems Are Solved DevFeed: [Why CRUD APIs Stop Teaching New Lessons After Basic Production Problems Are Solved]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [CRUD](), [REST API](), [Back end](), [SQL](), [Latency](), [Network](), [Redis]() Tags: [api](), [backend](), [cache-invalidation](), [career](), [crud](), [latency](), [learning](), [network](), [schema](), [schema-design](), [system-design]() ### AI overview A small CRUD API teaches backend fundamentals such as validation, schema design, migrations, query behavior, connection pooling, and cache invalidation. After those issues are understood, developers may need more complex failure domains involving cross-service contracts, event ordering, and slow downstream calls to continue learning. ### Source excerpt A todo CRUD API teaches real things, including validation, schema design, the N+1 query, index selection, pool sizing, and cache invalidation, and then it goes quiet. Boredom arriving right after you fix those once is not laziness; it is the signal that the problem stopped presenting decisions you have not already seen. The move is up the stack, to a failure domain with cross-service contracts, event ordering, and downstream calls that hang. ## Promotions are Proactive: The 3P Framework for Pitching Your Next Level DevFeed: [Promotions are Proactive: The 3P Framework for Pitching Your Next Level]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Back end](), [Latency](), [Caching](), [connection pool](), [migration]() Tags: [backend](), [caching](), [career](), [career-growth](), [connection-pool](), [engineering](), [latency](), [leadership](), [migration](), [scope](), [system-design]() ### AI overview This article presents the 3P framework--Problem, Proof, and Proactive pitch--for making an engineer's promotion case legible before review. It argues that promotion reflects the scope or blast radius of decisions, supported by system evidence and an explicit pitch. ### Source excerpt Promotion committees do not promote effort, they promote scope, and scope has to be legible before the vote rather than explained after it fails. Strip the leveling-guide language and the question is blast radius: a mid-level engineer's bad call fails one deploy unit, a senior's saturates a pool at 2 AM across teams. The 3P framework makes that visible: Problem at org scale, Proof in system metrics, and a Proactive pitch. ## Implementing LFU Cache in O(1) Time: A Hands-on Breakdown DevFeed: [Implementing LFU Cache in O(1) Time: A Hands-on Breakdown]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Cache](), [Caching](), [Data structures](), [implementation]() Tags: [algorithms](), [cache](), [caching](), [implementing](), [java](), [lfu](), [memory](), [order](), [performance](), [pointers](), [system-design]() ### AI overview This tutorial explains why LRU can evict a frequently requested product during a long-tail burst, then presents an O(1) LFU cache design. It contrasts a naive O(n) eviction scan with an implementation using key-to-node and frequency-to-bucket maps, doubly linked lists, and a minFreq pointer. ### Source excerpt LFU evicts the least frequently used key rather than the least recently used, which protects a hot key during a long-tail burst that would make LRU drop a bestseller. The naive implementation scans every key to find the minimum frequency, which is O(n) per eviction. The O(1) version inverts the index: a key-to-node map, a frequency-to-bucket map of doubly linked lists, and a minFreq pointer. ## AI speeds up code writing, but coordination across distributed services remains a system-design challenge DevFeed: [AI speeds up code writing, but coordination across distributed services remains a system-design challenge]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Artificial Intelligence](), [distributed-systems](), [backends](), [Microservice](), [migration](), [OpenAPI Specification]() Tags: [ai](), [alignment](), [architecture](), [backend](), [distributed-systems](), [migration](), [openapi](), [services](), [system-design]() ### AI overview The article argues that AI assistants have accelerated implementation work while leaving coordination between teams and services largely unchanged. It presents ownership boundaries, contract stability, migration coordination, and failure semantics as central system-design concerns because failures often occur between otherwise correct components. ### Source excerpt AI made the write path fast and left the coordination path untouched, so failures now live in the gaps between services: two event schema versions across two regions, three teams, and one assumption that someone else handled the migration window. Alignment work, deciding ownership boundaries, contract stability, and failure semantics before anyone opens an IDE, is system design, and it produces concrete network cost when skipped. ## How ORM N+1 Queries Create Hidden Request Latency DevFeed: [How ORM N+1 Queries Create Hidden Request Latency]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Object-relational mapping](), [Latency](), [Monitoring](), [lazy loading](), [Database](), [connection pool]() Tags: [connection-pool](), [database](), [database-performance](), [hibernate](), [latency](), [lazy-loading](), [monitoring](), [n-plus-one](), [observability](), [orm](), [query](), [request]() ### AI overview This article explains how ORM lazy loading can turn a loop over orders into an N+1 query pattern. Individual queries may remain fast and avoid slow-query alerts, while the accumulated network round trips increase request latency and hold connection-pool resources. It recommends monitoring queries per request and asserting query counts in tests. ### Source excerpt N+1 queries hide from monitoring because no individual query is slow. Four hundred queries at 0.4ms each never appear in the slow query log, never move p99 query latency, and still cost the request 300ms because the expense is the round trip rather than the execution. The metric that catches it is queries per request, and the only durable fix is asserting on that count in tests, since the code that causes it looks like a field access rather than I/O. ## I Rebuilt a Minimal BitTorrent Client in Go to Understand Peer-to-Peer Choking Algorithms DevFeed: [I Rebuilt a Minimal BitTorrent Client in Go to Understand Peer-to-Peer Choking Algorithms]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Algorithms](), [P2P](), [Go Language](), [Programming](), [Network]() Tags: [algorithms](), [bittorrent](), [distributed-systems](), [go](), [golang](), [network](), [networking](), [p2p](), [peer-to-peer](), [protocol](), [system-design]() ### AI overview A hands-on explanation of BitTorrent choking algorithms through rebuilding a minimal client in Go. The article describes choking as a decentralized bandwidth-allocation mechanism, explains the choked and interested states, and shows how upload capacity affects peer prioritization. ### Source excerpt The BitTorrent spec explains choking in two paragraphs; implementing it in Go and watching every peer choke you within 60 seconds is what makes it stick. Choking is a bandwidth allocator running independently on every node, not a courtesy flag. Upload is the scarce resource on an asymmetric link, and each connection carries just two booleans, choked and interested, whose four combinations drive the entire fairness policy of the swarm. ## Decoding isolation levels: I built a toy DB to force dirty reads and phantom reads DevFeed: [Decoding isolation levels: I built a toy DB to force dirty reads and phantom reads]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Databases](), [PostgreSQL](), [Python](), [MySQL](), [SQL](), [locking]() Tags: [concurrency](), [databases](), [isolation-levels](), [locking](), [mvcc](), [mysql](), [postgres](), [postgresql](), [python](), [sql](), [transactions]() ### AI overview A hands-on tutorial uses a roughly 200-line Python toy database to reproduce transaction anomalies and explain why isolation levels behave differently across PostgreSQL and MySQL InnoDB. It shows that the ANSI SQL isolation table does not fully describe engine behavior, including PostgreSQL's handling of READ UNCOMMITTED and REPEATABLE READ, and MySQL InnoDB's snapshot and next-key locking behavior. ### Source excerpt The ANSI isolation table lists which anomalies each level permits, but it does not describe what your engine actually does: Postgres silently upgrades READ UNCOMMITTED to READ COMMITTED, and its REPEATABLE READ prevents phantoms that the standard allows. Phantom reads are a locking problem rather than a row problem, because you cannot lock a row that does not exist yet. Snapshot isolation stops every anomaly the table names and still permits write skew, which the table never mentions. [Next page]()