A Pilot Study of Consistency–Latency Trade-offs in Distributed Caching Under Read-Heavy Concurrent Workloads

This research preprint reports a focused pilot study of consistency–latency trade-offs among direct PostgreSQL access, TTL cache-aside, invalidate-on-write, and write-through caching implemented as a database update followed by a synchronous Redis update. The experiment comprises 20 measured runs, with five repetitions per strategy, under one fixed condition: 95% read and 5% write probabilities, 50 virtual users, a 15-second warm-up, a 60-second measured duration, and a 30-second cache TTL. PostgreSQL, Redis, a Node.js/Fastify API, and the k6 load generator ran on one machine. Mean request p95 latency was 2.04 ms for baseline, 1.71 ms for TTL, 2.38 ms for invalidate-on-write, and 1.95 ms for write-through. Mean percentages of reads classified as stale were 98.22% for TTL, approximately 0.10% for invalidate-on-write, and approximately 0.11% for write-through. Latency combines GET and PUT requests; stale-read percentages use all successful reads as the denominator. The manuscript presents run-level statistics, 95% t confidence intervals for mean latency, and exploratory corrected pairwise comparisons. It discloses limitations of the process-local version oracle, including missing explicit resets and response-ordering effects. The results describe this instrumentation and tested condition; they do not establish formal consistency guarantees or universal strategy rankings. Generative AI assistance with implementation, analysis code, figures, and manuscript preparation is disclosed. Experimental observations came from executed software runs, not language-model-generated data. This is a research preprint and has not been peer-reviewed, accepted, or submitted to a conference or journal.