A Nearby Friends feature needs to know where each of your friends is right now. Not where they were an hour ago. The data has a very short useful life: a location update older than 30 seconds is essentially stale. This is ephemeral location storage: high-frequency writes, short TTL, and no need for historical persistence.

The Write Pattern#

Each mobile client sends location updates every 30 seconds while the app is active. At 10 million active users, that’s 333,000 writes per second. A relational database with durable disk writes can’t sustain this volume without massive over-provisioning.

Redis is the right layer. Each user has a key: location:{user_id} storing latitude, longitude, and timestamp. Set with TTL: SET location:user123 "37.7749,-122.4194,1719360000" EX 60. If the user stops sending updates, their key expires in 60 seconds and they appear offline. No cleanup job needed.

For geo-queries (“who is near me?”), Redis GEO commands: GEOADD friends_locations longitude latitude user_id followed by GEORADIUS friends_locations lon lat 1 mi. This runs in O(N+log(M)) where N is results returned and M is total entries.

graph TD A[Mobile client: location update every 30s] --> B[Location service] B --> C[Redis GEOADD: update position] B --> D[Redis SET location key EX 60] D --> E[TTL expires: user appears offline automatically] C --> F[GEORADIUS query: friends within 1 mile] F --> G[Return nearby friends list] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Sharding the Location Store#

A single Redis instance caps out around 100,000 writes per second. At 333,000 writes/sec, you need sharding. Shard by user ID: shard = user_id % num_shards. Each shard handles a subset of users. GEORADIUS queries now need to run against the shards that contain the querying user’s friends. Since you know the friend list, you know which shards to query.

Persistence Trade-offs#

Location data doesn’t need to survive a Redis restart. Set appendonly no and save "" to disable Redis persistence for location data. The next round of client updates will repopulate the store in 30 seconds. Disabling persistence doubles Redis write throughput by eliminating disk I/O.

At Oracle#

We tracked session heartbeats for 5G network functions: each function sent a heartbeat every 10 seconds. Functions that stopped heartbeating were considered failed. We used Redis with TTL of 3x the heartbeat interval (30 seconds). On Redis restart, all heartbeat keys were lost. Within 30 seconds, all active functions had re-registered. The TTL-based approach eliminated the need for explicit deregistration and handled crashes, network partitions, and clean shutdowns identically.

What I’m Learning#

Ephemeral location storage is a good reminder that not all data needs to be durable. When data has a natural expiry and clients regenerate it automatically, TTL-based eviction is simpler and faster than explicit deletion. The whole persistence layer simplifies when you accept that some data lives only in memory.

Have you used Redis TTL as a presence mechanism, and what edge cases did you run into?