Cleaning Up Shared Redis Keys After a Business Line Decommission: Challenges and Solutions

When a business line was discontinued, the team needed to release associated resources, including eight application servers, an Elasticsearch node, scheduled tasks, a MySQL database, and Redis cache data.

Because the Redis data (≈3 GB) was stored in a shared 16‑node, 128 GB cluster, the only safe way to free it was to delete the relevant keys without affecting other projects.

The main difficulties were the shared cluster and poorly‑named, scattered keys, many without expiration.

To locate the keys, the author searched the codebase for RedisTemplate and StringRedisTemplate , extracted key prefixes, generated wildcard patterns with a Python script, and used the SCAN command together with DEBUG OBJECT to obtain each key’s type, serialized length and TTL before deletion.

Key statistics were collected to calculate the reclaimed memory. The cluster contained about 70 million keys, and the cleanup finished after an overnight run.

After the incident, a custom Redis key‑prefix serializer was added to the shared component library to enforce a project‑specific prefix and to centralise key constants, preventing future cross‑project key collisions.

Configuration example:

spring:
  redis:
    prefix:
      enable: true
      key: E00P01

The new PrefixStringKeySerializer class adds the prefix during serialization and strips it during deserialization, with negligible performance impact.

By adopting these conventions, the team improves operational safety, simplifies future resource clean‑ups, and reinforces the importance of coding standards and code review.