Forem: 날다람쥐

useless-gps

날다람쥐 — Fri, 10 Apr 2026 17:50:44 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I made a useless-gps website.

Demo

useless-gps.vercel.app

Code

flyingsquirrel0419 / useless-gps

useless-gps

The world's most accurate and completely useless GPS locator.

This project is a small Next.js app that reads your browser geolocation and turns it into intentionally unhelpful cosmic, geophysical, and existential status cards.

Stack

Next.js 14
React 18
TypeScript
Tailwind CSS
Framer Motion

Local Development

Install dependencies:

npm ci

Start the development server:

npm run dev

Build for production:

npm run build

Start the production server:

npm run start

How It Works

Requests browser geolocation with high accuracy enabled
Shows a fake "scan" sequence while location data is loading
Converts coordinates into humorous location cards
Renders a stylized retro radar interface with animated effects

Contribution Policy

main is a protected branch.

Do not push directly to main
Open a pull request for every change
Outside contributors should work from a fork and open a PR
Non-admin changes require operator approval before landing on main

Operator Review

Repository ownership and…

View on GitHub

How I Built It

I am interesting in space.So i want to know location of earth in space. So i made it.

Prize Category

Community Favorite : Because i build this with own coding skills. so I should choose "Community Favorite".

layercache: Stop Paying Redis Latency on Every Hot Read

날다람쥐 — Thu, 09 Apr 2026 23:53:34 +0000

Every Node.js backend hits the same wall eventually.

Your Redis cache is working, latency is acceptable, and then traffic doubles. Suddenly the Redis round-trip that felt like nothing at 200 req/s starts dominating your p95 at 2,000 req/s. You add an in-process memory cache on top, wire up some invalidation logic by hand, and three months later you are maintaining a fragile two-layer system with no stampede protection and no cross-instance consistency.

layercache is a TypeScript-first library that solves this problem once, cleanly. It stacks memory, Redis, and disk behind a single unified API and handles the hard parts — stampede prevention, cross-instance invalidation, graceful degradation under Redis failures — out of the box.

This post walks through what it does and what the benchmark numbers actually look like on a real Redis backend.

The Core Idea

your app ──▶ L1 Memory   ~0.006 ms  (per-process, sub-millisecond)
                │
             L2 Redis    ~0.2 ms    (shared across instances)
                │
             L3 Disk     ~2 ms      (optional, persistent)
                │
             Fetcher     runs once  (even under high concurrency)

On a cache hit the fastest available layer responds and the result backfills any warmer layers automatically. On a miss the fetcher runs exactly once, no matter how many concurrent requests arrived at the same time.

That last part — the single-flight guarantee — is where most hand-rolled hybrid caches fall apart.

Getting Started

npm install layercache

Memory only (no Redis needed):

import { CacheStack, MemoryLayer } from 'layercache'

const cache = new CacheStack([
  new MemoryLayer({ ttl: 60, maxSize: 1_000 })
])

const user = await cache.get('user:123', () => db.findUser(123))

Memory + Redis layered setup:

import { CacheStack, MemoryLayer, RedisLayer } from 'layercache'
import Redis from 'ioredis'

const cache = new CacheStack([
  new MemoryLayer({ ttl: 60, maxSize: 2_000 }),
  new RedisLayer({ client: new Redis(), ttl: 300, prefix: 'myapp:' })
])

const user = await cache.get('user:123', () => db.findUser(123))

The API is the same regardless of how many layers you add. Your application code doesn't change when you add or remove a layer.

Benchmark Results

I ran layercache v1.2.9 against a real Redis 7 backend (Docker, not a mock) on Linux. Here is what the numbers look like.

Warm Hit Latency

The most important number for a cache library is how fast the hit path is.

Mode	Avg ms	P95 ms
No cache (origin)	5.175	8.742
Memory only	0.009	0.014
Memory + Redis	0.005	0.006

Memory-only warm hits averaged 0.009ms. With a Redis layer added, the hot path still resolves from L1 memory and came in at 0.005ms — both are firmly sub-millisecond and effectively the same class of latency for production purposes.

Stampede Prevention

This is where the library earns its keep. 75 concurrent requests for the same missing key, repeated 5 times:

Mode	Avg ms	Origin Executions
No cache	409.5	375
Memory only	6.9	5
Memory + Redis	36.7	5

Without a cache, 75 × 5 = 375 origin calls. With layercache, the fetcher ran exactly 5 times — once per round, regardless of concurrency. The layered case is slower than memory-only because it pays Redis coordination costs, but the correctness guarantee is the same.

HTTP Throughput

Under sustained load with autocannon (40 connections, 8 seconds):

Route	Avg Latency	P97.5	Req/s
No cache	249 ms	271 ms	161
Memory only	1.82 ms	4 ms	16,705
Memory + Redis	1.74 ms	4 ms	17,184

Caching moved the service from 161 req/s to over 17,000 req/s — roughly a 100× improvement in throughput. Average latency dropped from 249ms to under 2ms. The memory-only and layered routes performed nearly identically in steady state because hot requests stay in L1 after warm-up.

What Happens When Redis Is Slow or Dead?

This is the question that separates a library you can actually run in production from one you can only trust in demos.

Slow Redis

I measured three scenarios with injected TCP latency:

Redis Delay	L1 hot hit	L2 hit	Cold miss
0ms	0.407ms	2.655ms	12.259ms
100ms	0.119ms	101.172ms	504.167ms
500ms	0.196ms	501.404ms	2506.013ms

The key insight: L1 hot hits stayed fast regardless of Redis latency. If a request can be served from in-process memory, slow Redis does not matter at all. The latency penalty only applies when a request needs to reach L2 or perform a cold miss.

Cold misses scaled hard with injected delay because the request paid both the Redis round-trip and the write-back path. If you have traffic patterns with many cold misses, a slow Redis will drag your tail latency even with gracefulDegradation enabled — the benchmark showed graceful and strict modes performing nearly identically under slow conditions.

Dead Redis

Under a fully paused Redis instance:

Warm L1 hits: still worked — both strict and graceful modes served from memory normally
Cold misses: timed out at 2000ms — both modes failed

This is important to understand. gracefulDegradation keeps warm traffic alive when Redis goes down. It does not create a fast fallback path for cold keys. New keys and expired keys that need a Redis write-back will stall until the timeout.

Operationally this means: if your L1 TTL is shorter than your expected Redis outage window, you will see degraded cold-miss behavior. Size your L1 TTLs with this in mind.

Queue Amplification Under Slow Redis

A follow-up benchmark asked: if Redis is slow and 500 concurrent requests pile up on L2-hit traffic, does latency stay bounded or blow up?

Redis Delay	Concurrency 1	Concurrency 500	Amplification
100ms	100.8ms	128.9ms	1.28×
500ms	501.1ms	515.8ms	1.03×

No runaway queue amplification. At 500 concurrent requests against a 500ms-latency Redis, wall-clock time only grew by about 15ms above the single-request baseline. The library appears to batch or overlap L2 requests within a shared Redis client rather than serializing them, which keeps the curve nearly flat.

Memory Pressure and Eviction

With maxSize: 25 and 180 unique keys inserted (each with a 256KB payload), then revisiting the earliest 25 keys:

Evictions	L1 Retained	Revisit Avg	Origin Fetches
180	25	1.332ms	0

Eviction was predictable. L1 held exactly maxSize entries after the fill phase. When evicted keys were revisited, they reloaded from Redis L2 rather than hitting the origin — zero origin fetches despite L1 having evicted everything. GC activity was measurable (36 events, 78ms total) but no stop-the-world pauses appeared at this payload size.

Multi-Instance and Cross-Process Features

Single-process benchmarks only tell part of the story. layercache ships with primitives for distributed deployments:

import {
  CacheStack, MemoryLayer, RedisLayer,
  RedisInvalidationBus,
  RedisSingleFlightCoordinator
} from 'layercache'

const redis = new Redis()

const cache = new CacheStack(
  [
    new MemoryLayer({ ttl: 60, maxSize: 10_000 }),
    new RedisLayer({ client: redis, ttl: 3600 })
  ],
  {
    invalidationBus: new RedisInvalidationBus({
      publisher: redis,
      subscriber: new Redis() // separate connection for pub/sub
    }),
    singleFlightCoordinator: new RedisSingleFlightCoordinator({ client: redis }),
    gracefulDegradation: { retryAfterMs: 10_000 }
  }
)

The edge benchmark verified both of these features work:

Cross-instance invalidation: Instance B observed the updated value after Instance A invalidated and repopulated the key.
Distributed single-flight: 60 concurrent requests split across two instances triggered exactly 1 origin fetch total.

TTL expiry stampedes are also deduplicated. In the benchmark, 40 concurrent requests hitting the same expired key across 5 rounds produced only 5 origin executions — one per expiry round.

Framework Integrations

layercache ships middleware and adapters for the major Node.js frameworks:

Express:

app.get('/api/users', createExpressCacheMiddleware(cache, {
  ttl: 30,
  tags: ['users'],
  keyResolver: (req) => `users:${req.url}`
}), handler)

NestJS:

@Module({
  imports: [CacheStackModule.forRoot({
    layers: [
      new MemoryLayer({ ttl: 20 }),
      new RedisLayer({ client: redis, ttl: 300 })
    ]
  })]
})
export class AppModule {}

Fastify, Hono, tRPC, GraphQL resolver wrappers, and Next.js App Router are also covered.

Payload Size Matters for Redis Reads

One benchmark result worth highlighting explicitly: payload size has almost no effect on L1 memory hits, but has a large effect when Redis is on the read path.

Mode	1KB avg	1MB avg
Memory hit	0.012ms	0.018ms
Redis hit	0.200ms	4.170ms

If you are storing large objects — full page renders, heavy API responses — and relying on Redis as the primary read path without a warm L1 in front, you will feel the serialization and network overhead. Keep large objects in L1 where possible, or enable compression at the Redis layer.

When to Use layercache

Good fit:

Services handling repeated reads for the same keys under any meaningful concurrency
Multi-instance deployments that need consistent cache state across processes
Situations where Redis slowdowns or outages should degrade gracefully rather than cascade
Teams that want observable caching with hits/misses/latency metrics without building the instrumentation themselves

Less relevant:

Pure write-heavy workloads with no repeated reads
Environments where an in-process memory cache is prohibited for compliance reasons
Very simple single-key caches where a plain Map with a TTL is already sufficient

Summary

Scenario	Key number
Warm L1 hit latency	~0.006ms
HTTP throughput gain (no cache → cached)	~100×
Stampede dedup (75 concurrent, 5 rounds)	375 fetches → 5
Distributed single-flight (60 requests, 2 instances)	60 fetches → 1
Slow Redis impact on hot L1 traffic	None
Dead Redis impact on warm L1 traffic	None
Dead Redis impact on cold-miss traffic	Timeout

The library makes a clear promise: stack your layers, wire up your fetcher, and it handles the coordination. The benchmarks back that promise up on a real backend.

Links:

Beyond Basic Caching: How layercache Eliminates Cache Stampedes in Node.js

날다람쥐 — Thu, 09 Apr 2026 18:21:03 +0000

Every Node.js developer knows the caching drill. You start with an in-memory Map, graduate to Redis when you scale horizontally, and eventually find yourself wiring up a fragile hybrid system that breaks in production at 2 AM.

I recently discovered layercache—a multi-layer caching toolkit that promises to handle the messy parts (stampede prevention, graceful degradation, distributed consistency) while keeping the API simple. But does it deliver?

I ran four comprehensive benchmark suites against real Redis instances to find out. Here are the results.

The Architecture: L1 + L2 + Coordination

layercache treats caching as a stack:

┌─────────────────────────────────────┐
│  L1 Memory  (~0.01ms, per-process)  │
│  L2 Redis   (~0.5ms, shared)        │
│  L3 Disk    (~2ms, persistent)      │
└─────────────────────────────────────┘

When you request a key, it checks L1 first, then L2, then your database. The clever part? All layers backfill automatically—if you hit L2, layercache populates L1 for the next request. If you hit the database, it writes to both layers.

But the real magic happens when 100 requests arrive simultaneously for the same expired key.

Benchmark 1: The Stampede Test

The "thundering herd" problem is where most caching libraries fail. When a popular key expires, 100 concurrent requests can trigger 100 database queries before the first one repopulates the cache.

I tested 75 concurrent requests across 5 runs (375 total requests) for a cold key:

Setup	Origin Fetches
No cache	375
Memory-only	5
Memory + Redis	5

Result: layercache's single-flight coordination ensured the fetcher ran exactly once per expiry round, not 75 times. The library creates a coordination lock in Redis (or memory) so that concurrent requests wait for the first fetcher to complete rather than hammering your database.

Latency under this stampede:

Mode	Avg Latency	P95
No cache	409ms	429ms
Memory-only	6.9ms	13.5ms
Layered	36.7ms	43.6ms

The layered case is slower than memory-only (it pays Redis coordination costs), but it preserves the critical property: your database only feels one request.

Benchmark 2: Real HTTP Throughput

Theory is nice, but what about real HTTP servers? I set up three Express routes—no cache, memory-only, and layered—and hit them with autocannon (40 connections, 8 seconds):

Route	Avg Latency	P97.5	Req/sec	Throughput
`/nocache`	249ms	271ms	161	57 KB/s
`/memory`	1.82ms	4ms	16,705	5.9 MB/s
`/layered`	1.74ms	4ms	17,184	6.1 MB/s

That's a 100x throughput increase with minimal latency difference between memory-only and Redis-backed layers. Once warmed, L1 memory serves the hot path while Redis provides the shared backing store for multi-instance deployments.

Benchmark 3: When Redis Goes Wrong

Production caches fail. I tested two failure modes:

Slow Redis (500ms latency injection)

Using a TCP proxy to add synthetic latency:

Scenario	Single Request	500 Concurrent	Amplification
L2 hit (strict)	501ms	515ms	1.03x
L2 hit (graceful)	501ms	512ms	1.02x

Key finding: Under slow Redis, wall-clock time stayed close to the single-request baseline even at 500 concurrent requests. The linearity ratio collapsed to ~0.002, meaning the batch completed far faster than a naive "latency × N" model would predict.

However, cold misses were brutal: With 500ms Redis latency, a cache miss took ~2.5s because it paid the slow Redis cost plus the fetch/write cost.

Dead Redis (complete outage)

I paused the Redis container with Docker:

Scenario	Success	Latency
Strict hot hit	✅	0.17ms
Graceful hot hit	✅	0.07ms
Strict cold miss	❌	Timeout (2000ms)
Graceful cold miss	❌	Timeout (2000ms)

Critical insight: gracefulDegradation did not turn a cold miss into a fast memory-only fallback when Redis was completely frozen. Hot L1 keys survived the outage beautifully (served from memory), but new or expired keys stalled until timeout.

Operational takeaway: Warm your critical keys before Redis has issues. Hot L1 traffic is your lifeline during Redis outages.

Benchmark 4: Memory Pressure and Eviction

What happens when L1 memory fills up? I set maxSize: 25 and inserted 180 unique 256KB payloads:

Metric	Value
Evictions	180
L1 Retained	25 (exactly maxSize)
Origin Fetches on Revisit	0
GC Pauses (max)	6.1ms

When revisiting the oldest keys (which were evicted from L1), they were seamlessly reloaded from Redis L2—not the origin. No cache stampede, no origin amplification.

The GC impact was measurable (36 events, 78ms total) but not catastrophic—max pause stayed at 6ms, far from stop-the-world territory.

Edge Cases: TTL Expiry and Distributed Systems

TTL Stampede Protection

I tested 40 concurrent requests hitting a key that just expired (TTL: 1s, waited 1.1s):

Mode	Fetch Count
Memory-only	5 (one per expiry round)
Layered	5 (one per expiry round)

Even with TTL expiry triggering simultaneously across multiple rounds, deduplication held firm.

Multi-Instance Consistency

Running two Node.js instances with shared Redis:

Invalidation Bus: When Instance A updated a key, Instance B's L1 cache was invalidated via Redis Pub/Sub within milliseconds.
Distributed Single-Flight: 60 concurrent requests across both instances for the same missing key resulted in exactly 1 origin fetch.

This is the holy grail for microservices: you get per-process L1 speed with cluster-wide consistency.

Payload Size Sensitivity

Does caching large objects hurt?

Setup	1KB Avg	1MB Avg	P95 (1MB)
Memory-only	0.012ms	0.018ms	0.023ms
Redis-only	0.200ms	4.170ms	10.11ms

Large payloads hurt only when Redis is on the hot path. Memory hits barely changed between 1KB and 1MB, but Redis hits jumped 20x due to serialization and network transfer. Keep your L1 maxSize generous for large objects.

Practical Takeaways

After running these benchmarks, here are my operational recommendations:

Use layered caching for multi-instance deployments. The hot-hit latency is identical to memory-only (~0.005ms), but you get distributed consistency and stampede prevention.
Warm your cache before traffic spikes. Cold misses under slow Redis are painful (~2.5s), and dead Redis won't gracefully degrade for new keys.
Set generous L1 limits for large payloads. 1MB objects in Redis are 200x slower than in memory. Let L1 absorb that cost.
Don't rely on graceful degradation for cold keys. It protects hot L1 traffic during outages, but new keys will still timeout.
Trust the stampede prevention. The library correctly handled 75→1 fetch reduction even with TTL expiry and cross-instance coordination.

Getting Started

Basic setup:

import { CacheStack, MemoryLayer, RedisLayer } from 'layercache'
import Redis from 'ioredis'

const cache = new CacheStack([
  new MemoryLayer({ ttl: 60, maxSize: 10_000 }),
  new RedisLayer({ client: new Redis(), ttl: 3600 })
])

// Automatic stampede prevention
const user = await cache.get('user:123', () => db.findUser(123))

For distributed deployments, wire up the invalidation bus:

import { RedisInvalidationBus, RedisSingleFlightCoordinator } from 'layercache'

const cache = new CacheStack([
  new MemoryLayer({ ttl: 60 }),
  new RedisLayer({ client: redis })
], {
  invalidationBus: new RedisInvalidationBus({ 
    publisher: redis, 
    subscriber: new Redis() 
  }),
  singleFlightCoordinator: new RedisSingleFlightCoordinator({ client: redis }),
  gracefulDegradation: { retryAfterMs: 10_000 }
})

The Verdict

layercache delivers on its promises. The benchmark data shows it handles the three hard problems of production caching—stampede prevention, graceful degradation, and distributed consistency—without sacrificing the performance of simple in-memory caching.

The 100x HTTP throughput improvement and zero-fetch stampede protection make it a strong candidate for any Node.js service moving beyond a single instance.

Have you solved cache stampedes differently? I'd love to hear your war stories in the comments.

Links:

npm: layercache
GitHub Repository
Benchmark environment: Node.js v20.20.1, Redis 7-alpine, Linux 5.15

I built a multi-layer caching library for Node.js — would love your feedback!

날다람쥐 — Wed, 08 Apr 2026 17:51:00 +0000

Hey dev.to community! 👋

I've been working on a side project for a while now and finally got it to a point where I feel comfortable sharing it publicly. It's called layercache — a multi-layer caching toolkit for Node.js.

I'd really appreciate any feedback, honest criticism, or ideas from folks who deal with caching in production. Here's the quick overview:

Why I built this

Almost every Node.js service I've worked on eventually hits the same caching problem:

Memory-only cache → Fast, but each instance has its own isolated view of data
Redis-only cache → Shared across instances, but every request still pays a network round-trip
Hand-rolled hybrid → Works at first, then you need stampede prevention, tag invalidation, stale serving, observability... and it spirals fast

I couldn't find a library that handled all of this cleanly in one place, so I built one.

What layercache does

layercache lets you stack multiple cache layers (Memory → Redis → Disk) behind a single unified API. On a cache hit, it serves from the fastest available layer and backfills the rest. On a miss, the fetcher runs exactly once — even under high concurrency.

              ┌───────────────────────────────────────┐
your app ---->│             layercache                │
              │                                       │
              │  L1 Memory    ~0.01ms  (per-process)  │
              │      |                                │
              │  L2 Redis     ~0.5ms   (shared)       │
              │      |                                │
              │  L3 Disk      ~2ms     (persistent)   │
              │      |                                │
              │  Fetcher      ~20ms    (runs once)    │
              └───────────────────────────────────────┘

Basic usage

npm install layercache

import { CacheStack, MemoryLayer, RedisLayer } from 'layercache'
import Redis from 'ioredis'

const cache = new CacheStack([
  new MemoryLayer({ ttl: 60, maxSize: 1_000 }),       // L1: in-process
  new RedisLayer({ client: new Redis(), ttl: 3600 }),  // L2: shared
])

// Read-through: fetcher runs once, all layers filled automatically
const user = await cache.get('user:123', () => db.findUser(123))

You can also start with just memory (no Redis required) and add layers as your needs grow.

Key features I'm most proud of

Stampede prevention — 100 concurrent requests for the same key trigger only 1 fetcher execution. Distributed dedup via Redis locks works across multiple server instances too.

Tag-based invalidation — Invalidate groups of related keys by tag, including across all layers at once. Useful for things like "invalidate all user-related cache entries."

Stale-while-revalidate / stale-if-error — Serve the stale cached value immediately while refreshing in the background, or keep serving stale data when the upstream is down.

Framework integrations — Middleware helpers for Express, Fastify, Hono, tRPC, GraphQL, and a NestJS module with a @Cacheable() decorator.

Observability out of the box — Prometheus exporter, OpenTelemetry tracing, per-layer latency metrics, event hooks, and an HTTP stats endpoint.

Admin CLI — npx layercache stats|keys|invalidate for Redis-backed caches.

NestJS example (because I use NestJS a lot)

// app.module.ts
@Module({
  imports: [
    CacheStackModule.forRoot({
      layers: [
        new MemoryLayer({ ttl: 20 }),
        new RedisLayer({ client: redis, ttl: 300 })
      ]
    })
  ]
})
export class AppModule {}

// user.service.ts
@Injectable()
export class UserService {
  constructor(@InjectCacheStack() private readonly cache: CacheStack) {}

  async getUser(id: number) {
    return this.cache.get(`user:${id}`, () => this.db.findUser(id))
  }
}

Benchmark numbers (on my machine, grain of salt)

Scenario	Avg Latency
L1 memory hit	~0.006 ms
L2 Redis hit	~0.020 ms
No cache (simulated DB)	~1.08 ms

Stampede prevention: 100 concurrent requests → 1 fetcher execution.

What I'm looking for feedback on

Honestly, everything! But a few things I'm specifically unsure about:

API design — Does the CacheStack + layer composition model feel intuitive? Are there footguns I'm missing?
The feature set — Is this too much? Too little? Are there things here that should just be separate libraries?
Production readiness — What would you need to see before using something like this in production? (more tests? better docs? battle-tested examples?)
Naming / discoverability — layercache as a name... does it communicate what it does clearly enough?
Anything else — I'm sure there are patterns or edge cases I haven't thought of.