Part 037 — Redis Memory Management

Redis adalah sistem yang sangat cepat karena data utamanya berada di memory.

Namun konsekuensinya jelas:

Redis performance problem sering kali bukan dimulai dari CPU, tetapi dari memory model yang tidak dipahami.

Memory di Redis bukan hanya ukuran value yang Anda simpan. Memory mencakup:

• key name
• value object
• Redis object metadata
• internal encoding
• allocator overhead
• fragmentation
• client buffers
• replication buffers
• Lua/script execution impact
• stream pending metadata
• AOF/rewrite temporary pressure
• cluster overhead

Untuk Java/JAX-RS backend, Redis memory problem biasanya terlihat sebagai:

• latency naik
• eviction tiba-tiba
• cache hit ratio turun
• stream pending entries membesar
• limiter key tumbuh tanpa cleanup
• idempotency key tidak punya TTL
• big key membuat command lambat
• Redis restart/failover lebih sering
• node kehabisan memory
• managed Redis menolak write

Redis memory management bukan hanya urusan platform/SRE. Senior backend engineer perlu memahami karena aplikasi yang menentukan key cardinality, TTL, payload size, dan access pattern.

1. Core Mental Model

Redis menyimpan data di memory.

Secara konseptual:

application writes key/value
        ↓
Redis creates internal objects
        ↓
allocator reserves memory pages
        ↓
Redis reports logical used memory
        ↓
OS reports resident memory
        ↓
fragmentation can make RSS larger than logical data

Memory yang terlihat di Redis dan memory yang terlihat di OS tidak selalu sama.

Redis dapat mengatakan used_memory sekian, tetapi OS menunjukkan RSS lebih besar karena fragmentation, allocator behavior, copy-on-write, atau buffer.

2. Important Memory Terms

Beberapa istilah utama:

Senior engineer perlu membaca metric ini sebagai sinyal desain aplikasi, bukan hanya angka infra.

3. Maxmemory

maxmemory adalah batas memory Redis.

Jika Redis mencapai maxmemory, behavior tergantung eviction policy.

Contoh konseptual:

maxmemory = 8 GB
used_memory approaches 8 GB
        ↓
Redis applies eviction policy
        ↓
write command may evict key or fail

Jika eviction policy adalah noeviction, write yang membutuhkan memory baru dapat gagal.

Dari perspektif Java service:

HTTP request
  -> service writes idempotency key
  -> Redis returns OOM / command error
  -> application must decide fail closed or continue

Untuk cache, failure mungkin bisa degrade. Untuk idempotency, rate limiter, lock, atau session, failure behavior harus eksplisit.

4. Used Memory vs RSS

used_memory adalah logical memory yang dikelola Redis. used_memory_rss adalah memory resident yang dilihat OS.

Contoh:

used_memory     = 4.0 GB
used_memory_rss = 6.2 GB

Ini berarti Redis process menempati lebih banyak memory resident daripada logical Redis objects.

Penyebab umum:

• fragmentation
• allocator page reuse belum optimal
• workload banyak allocate/free
• big key churn
• copy-on-write saat RDB/AOF rewrite
• client buffers

Jangan langsung menyimpulkan memory leak. Sering kali ini workload/allocator pattern.

5. Memory Fragmentation

Fragmentation terjadi saat memory yang dialokasikan tidak bisa digunakan ulang secara ideal.

Analogi sederhana:

Memory pages:
[used][free small][used][free small][used]

Walaupun total free space ada, bentuknya tersebar dan tidak cocok untuk alokasi baru.

Redis dapat memiliki fragmentation tinggi saat:

• banyak key expire/delete
• payload size bervariasi
• big key sering berubah ukuran
• hash/list/set/zset tumbuh dan menyusut
• workload write-heavy
• AOF rewrite/RDB snapshot sedang berjalan

Failure mode:

• RSS tinggi
• container memory limit tertekan
• pod OOMKilled
• managed Redis memory alarm
• latency meningkat karena allocator pressure

6. Jemalloc Awareness

Redis umumnya dikaitkan dengan allocator seperti jemalloc pada banyak deployment.

Yang perlu dipahami backend engineer bukan detail internal allocator, tetapi implikasinya:

• memory tidak selalu langsung kembali ke OS setelah key dihapus
• fragmentation bisa naik setelah churn besar
• used_memory turun tetapi RSS tetap tinggi
• restart kadang terlihat "membersihkan" RSS, tetapi bukan solusi desain

Operational mistake umum:

Menganggap DEL banyak key pasti langsung menurunkan RSS.

Yang benar:

DEL menurunkan logical data. RSS bisa tetap tinggi karena allocator dan fragmentation.

7. Object Overhead

Redis key kecil tidak gratis.

Setiap key memiliki overhead:

• key string
• Redis object metadata
• dictionary entry
• expiry dictionary entry jika punya TTL
• value object metadata
• allocator overhead

Karena itu jutaan key kecil bisa menghabiskan memory besar meskipun value sangat kecil.

Contoh buruk:

rate:{tenant}:{user}:{endpoint}:{second} -> "1"

Jika cardinality tinggi dan TTL cleanup tidak disiplin, memory bisa naik cepat.

Lebih buruk lagi jika key name panjang:

production:quote-order-service:tenant:very-long-tenant-id:endpoint:/api/v1/quote/validate:user:very-long-user-id:timestamp:...

Key naming harus readable, tetapi tidak boros secara ekstrem.

8. Key Name Memory Cost

Key name adalah data juga.

Dalam enterprise system, key sering dibuat terlalu verbose karena ingin self-documenting.

Trade-off:

Contoh lebih seimbang:

qo:cache:quote:v1:{tenantId}:{quoteId}
qo:rl:v1:{tenantId}:{userId}:{endpointHash}
qo:idem:v1:{tenantId}:{idempotencyKey}

Gunakan hash pendek untuk bagian yang sangat panjang seperti endpoint atau fingerprint, tetapi jangan hilangkan kemampuan traceability.

9. Value Size Matters

Redis sering dipakai untuk menyimpan JSON object.

Masalahnya, object Java yang tampak kecil bisa menjadi payload besar setelah serialization.

Contoh risiko:

Quote aggregate -> JSON 350 KB
Cached for each tenant + user + scenario
10,000 active keys
≈ 3.5 GB raw payload, belum termasuk overhead

Value besar memengaruhi:

• memory
• network transfer
• serialization/deserialization latency
• GC pressure di Java service
• Redis event loop time
• replication bandwidth
• persistence rewrite cost
• cluster migration cost

Cache bukan alasan untuk menyimpan aggregate raksasa tanpa batas.

10. Big Key Memory Impact

Big key bukan hanya masalah memory.

Big key menyebabkan:

• command lebih lama
• network payload besar
• replication lebih berat
• failover/recovery lebih berat
• deletion bisa memblokir jika tidak asynchronous
• cluster slot hotspot
• Java deserialization spike

Contoh big key:

hash with 1,000,000 fields
list with millions of jobs
set with millions of members
stream without trimming
JSON string hundreds of KB or MB

Senior review question:

Apakah key ini punya upper bound yang jelas?

Jika jawabannya tidak, key tersebut adalah incident candidate.

11. Encoding Optimization

Redis menggunakan internal encoding berbeda untuk struktur tertentu agar hemat memory.

Misalnya secara konseptual:

• small hash dapat disimpan compact
• small list-like structures dapat disimpan compact
• small integer set dapat disimpan compact
• sorted set punya encoding yang berubah saat membesar

Engineer aplikasi tidak perlu menghafal semua detail encoding. Yang penting:

• struktur kecil bisa sangat efisien
• struktur yang tumbuh melewati threshold bisa berubah encoding
• perubahan encoding dapat menaikkan memory dan CPU cost
• config encoding threshold biasanya urusan platform, tetapi data model aplikasi yang memicu perubahan

Jika hash kecil tiba-tiba menjadi wide hash besar, behavior memory/performance bisa berubah drastis.

12. Expiration and Memory

TTL membantu memory cleanup, tetapi bukan jaminan memory selalu stabil.

Redis expiration bekerja melalui kombinasi:

• passive expiration saat key diakses
• active expiration background sampling

Implikasi:

many keys expire at same time
        ↓
active expiration work increases
        ↓
latency may spike
        ↓
memory may not drop instantly

Gunakan TTL jitter untuk key massal.

Contoh:

baseTtlSeconds = 3600
jitterSeconds = random(0, 300)
finalTtl = baseTtlSeconds + jitterSeconds

Tanpa jitter, semua key yang dibuat saat deployment/cache warming bisa expired bersamaan.

13. Eviction and Memory Safety

Eviction bukan cleanup normal. Eviction adalah tanda Redis berada di bawah memory pressure.

Untuk cache-only Redis, eviction mungkin acceptable jika didesain. Untuk idempotency/session/lock/queue, eviction bisa merusak correctness.

Contoh dampak:

Karena itu jangan mencampur semua use case ke satu Redis tanpa memahami eviction boundary.

14. Cache Redis vs Coordination Redis

Pattern production yang lebih aman:

Redis for cache
  eviction allowed depending on policy

Redis for coordination/idempotency/session
  eviction should usually be avoided or tightly controlled

Jika semua use case berbagi satu Redis instance dengan eviction policy agresif, cache traffic dapat mengusir key correctness-critical.

Senior architecture question:

Apakah Redis cache workload dan Redis correctness workload dipisahkan secara topology, database, namespace, policy, atau at least quota?

Jika tidak, satu traffic spike cache dapat menjadi security/correctness incident.

15. Memory Leak-Like Growth

Redis tidak "leak" dalam arti aplikasi Java leak object, tetapi dari luar dapat terlihat seperti leak.

Penyebab umum:

• key tanpa TTL
• TTL tidak dipasang karena code path error
• idempotency keys tidak expired
• rate limiter keys cardinality terlalu tinggi
• stream tidak di-trim
• pending entries tidak di-ack/claim
• job queue worker stuck
• cache key version terus bertambah tanpa cleanup
• tenant/entity cardinality tidak dipahami
• Pub/Sub tidak menyimpan pesan, tetapi subscriber buffers bisa membesar jika client lambat

Diagnosis awal:

Is memory growth correlated with:
- traffic?
- tenant count?
- new deployment?
- failed worker?
- invalidation event?
- stream consumer lag?
- rate limiter rollout?

16. Stream Memory Growth

Redis Streams punya risiko memory khusus.

Memory stream dapat tumbuh dari:

• entries yang tidak di-trim
• consumer group metadata
• Pending Entry List
• consumer yang mati tetapi tidak dibersihkan
• message payload besar
• retry loop yang menambah DLQ-like stream

Contoh failure:

worker stops ACKing
        ↓
PEL grows
        ↓
stream memory grows
        ↓
Redis memory pressure
        ↓
eviction or write failure

Stream harus punya retention policy:

XTRIM MAXLEN approximate
or
XTRIM MINID based on age

Retention harus cocok dengan replay requirement.

17. Rate Limiter Memory Growth

Rate limiter sering menciptakan key cardinality tinggi.

Contoh:

rl:{tenant}:{user}:{endpoint}:{window}

Risiko:

• tenant banyak
• user banyak
• endpoint banyak
• window granular terlalu kecil
• TTL gagal dipasang
• sorted set sliding log tidak dibersihkan

Sliding log dengan sorted set harus cleanup entry lama.

Contoh konseptual:

ZREMRANGEBYSCORE rl:key -inf now-window
ZCARD rl:key
ZADD rl:key now requestId
EXPIRE rl:key ttl

Jika cleanup lupa, memory tumbuh per request.

18. Idempotency Store Memory Growth

Idempotency record wajib punya TTL.

Tanpa TTL, setiap request unik akan meninggalkan state permanen.

Namun TTL terlalu pendek juga berbahaya:

client timeout
client retries after key expired
        ↓
server processes duplicate

Memory design idempotency harus mempertimbangkan:

• traffic write API
• retry window client
• business duplicate tolerance
• response payload size
• completed state TTL
• failed/unknown state TTL
• processing state TTL

Jika response replay disimpan, payload bisa besar. Mungkin perlu menyimpan reference ke database record, bukan full response besar.

19. Session and Token Memory Growth

Session/token data biasanya expiring, tetapi cardinality bisa tinggi.

Risiko:

• sliding session memperpanjang TTL terus-menerus
• token blacklist tumbuh sampai token natural expiry
• refresh token state menyimpan metadata besar
• login attempt counters per IP/user/tenant terlalu granular
• logout propagation menambah key sementara

Security-state Redis harus punya sizing berdasarkan:

active users
sessions per user
token lifetime
payload size
peak login attempts
retention requirement

Jangan mendesain session store hanya dari average traffic. Desain dari peak dan attack scenario.

20. Client Buffers

Redis memory juga dipakai untuk client buffers.

Output buffer bisa membesar jika:

• client lambat membaca response
• command menghasilkan response besar
• Pub/Sub subscriber lambat
• network congestion
• consumer stuck

Dari sisi Java service:

• jangan ambil response sangat besar
• hindari SMEMBERS pada set besar
• hindari full HGETALL untuk hash besar tanpa upper bound
• gunakan scan/range dengan limit
• timeout client harus jelas

Client buffer problem bisa tampak seperti Redis memory problem, padahal root cause adalah aplikasi lambat membaca atau command terlalu besar.

21. Replication and Persistence Memory Pressure

Replication dan persistence dapat menambah memory pressure.

Situasi umum:

• replica tertinggal sehingga replication buffer membesar
• RDB snapshot memicu copy-on-write overhead
• AOF rewrite memicu extra memory/disk pressure
• network lambat ke replica
• big write during background save

Dampak:

normal memory usage: 60%
RDB/AOF rewrite starts
copy-on-write pressure increases
RSS spikes
container/VM memory limit hit
Redis killed or degraded

Capacity planning harus menyisakan headroom untuk operasi background.

22. Memory Sizing Model

Sizing Redis harus berbasis data model, bukan feeling.

Formula kasar:

total_memory ≈
  key_count × average_key_overhead
+ value_count × average_value_size
+ data_structure_overhead
+ expiry_metadata
+ client_buffers
+ replication_buffers
+ fragmentation_headroom
+ persistence_headroom
+ growth_headroom

Untuk cache:

expected_keys = active_entities × variants × tenants × versions

Untuk rate limiter:

expected_keys = tenants × users × endpoints × active_windows

Untuk idempotency:

expected_keys = write_requests_per_second × retention_seconds

Untuk streams:

stream_memory = events_per_second × retention_seconds × average_event_size + consumer_group_metadata

23. Capacity Headroom

Redis yang berjalan di 90–95% memory bukan sehat.

Butuh headroom untuk:

• traffic spike
• failover
• replication backlog
• RDB/AOF rewrite
• fragmentation
• cache warming
• deployment bug
• tenant growth
• retry storm

Rule praktis:

Do not size Redis only for steady state.
Size for failure, rebuild, retry, and operational background work.

Headroom requirement berbeda untuk cache-only vs correctness-critical Redis.

24. Java/JAX-RS Impact

Redis memory pressure memengaruhi Java service dalam beberapa bentuk:

• command timeout
• OOM command error
• cache miss spike
• fallback path aktif massal
• database overload
• response latency naik
• rate limiter inconsistency
• idempotency failure
• session loss
• lock failure

JAX-RS resource tidak boleh menganggap Redis operation selalu cepat dan berhasil.

Contoh boundary:

// conceptual only
try {
    Optional<CachedQuote> cached = quoteCache.get(cacheKey);
    if (cached.isPresent()) {
        return Response.ok(cached.get()).build();
    }

    Quote quote = quoteRepository.load(quoteId);
    quoteCache.set(cacheKey, quote, ttlWithJitter());
    return Response.ok(quote).build();
} catch (RedisUnavailableException ex) {
    // cache failure should not necessarily fail read path
    Quote quote = quoteRepository.load(quoteId);
    return Response.ok(quote).build();
}

Tetapi untuk idempotency atau security state, fallback bisa berbeda.

25. PostgreSQL/MyBatis/JDBC Impact

Redis memory issue dapat berpindah menjadi PostgreSQL issue.

Contoh:

Redis evicts many cache keys
        ↓
cache hit ratio drops
        ↓
Java services reload from PostgreSQL
        ↓
DB CPU/connection pool saturates
        ↓
API latency increases

Cache memory sizing harus memperhitungkan database protection.

Pertanyaan review:

• Jika 30% cache hilang, apakah PostgreSQL kuat?
• Jika Redis flush/restart, apakah ada cache warming strategy?
• Jika eviction spike terjadi, apakah query MyBatis punya index dan limit yang aman?
• Apakah fallback path menyebabkan N+1 query?

26. Kafka/RabbitMQ Impact

Redis memory issue juga berdampak ke messaging:

• consumer gagal update Redis projection
• invalidation event backlog naik
• retry storm ke Redis
• DLQ meningkat
• stream/queue Redis ikut memory pressure
• cache rebuild dari Kafka replay terlalu agresif

Event-driven cache harus punya backpressure.

Contoh strategi:

Kafka replay -> bounded Redis writes -> monitor memory + latency -> pause/throttle consumer if needed

Jangan replay jutaan event ke Redis tanpa rate limit dan memory guard.

27. Kubernetes Impact

Di Kubernetes, memory issue sering terlihat sebagai:

• pod OOMKilled
• restart loop
• readiness failure
• node memory pressure
• eviction oleh kubelet
• PVC not the issue, memory is

Redis StatefulSet harus punya resource planning yang realistis.

Bahaya umum:

resources:
  limits:
    memory: 2Gi

Tetapi maxmemory Redis juga 2Gi.

Tidak ada ruang untuk RSS overhead, fragmentation, buffers, dan background work.

Lebih aman secara konseptual:

container_memory_limit > redis_maxmemory + overhead_headroom

Internal platform config harus diverifikasi.

28. AWS/Azure/Managed Redis Impact

Managed Redis tidak menghilangkan memory design problem.

Managed service membantu:

• monitoring
• failover
• backup
• maintenance
• scaling option

Tetapi aplikasi tetap menentukan:

• key count
• payload size
• TTL
• eviction sensitivity
• stream retention
• rate limiter cardinality
• idempotency retention

Managed Redis biasanya punya metric seperti:

• memory usage percentage
• evictions
• CPU
• connections
• replication lag
• cache hit/miss

Internal verification harus melihat metric nyata di AWS/Azure/on-prem, bukan asumsi dari local Redis.

29. Production-Safe Memory Diagnosis

Jangan mulai debugging dengan command yang scan seluruh keyspace secara brutal.

Production-safe approach:

1. Check memory metrics
2. Check eviction/expiration trend
3. Check top command stats
4. Check keyspace cardinality by DB/prefix if available
5. Check recent deployment/traffic change
6. Check known high-cardinality features
7. Use sampled SCAN, not KEYS
8. Use MEMORY USAGE on sampled keys
9. Confirm with SRE/platform before intrusive operation

Hindari:

KEYS *
SMEMBERS huge:set
HGETALL huge:hash
LRANGE huge:list 0 -1
ZRANGE huge:zset 0 -1
MONITOR on busy production

30. Useful Redis Memory Commands

Commands yang sering relevan:

INFO memory
INFO stats
INFO keyspace
MEMORY STATS
MEMORY USAGE <key>
MEMORY DOCTOR
SLOWLOG GET
CLIENT LIST

Gunakan dengan hati-hati:

SCAN
HSCAN
SSCAN
ZSCAN

Command untuk deletion:

DEL      -> synchronous deletion
UNLINK   -> asynchronous deletion where available/appropriate

Untuk big key deletion, UNLINK sering lebih aman daripada DEL, tetapi tetap harus diverifikasi dengan platform/team dan compatibility deployment.

31. Common Memory Failure Modes

31.1 Eviction Spike

Symptoms:

• evicted_keys naik
• cache hit ratio turun
• DB load naik
• latency naik

Likely causes:

• cache warming terlalu besar
• TTL tidak merata
• maxmemory terlalu rendah
• payload membesar setelah release
• key cardinality naik

Mitigation:

• rollback payload/key explosion
• tambah TTL jitter
• reduce payload size
• split workload
• scale memory if justified

31.2 Fragmentation Spike

Symptoms:

• RSS jauh lebih tinggi dari used memory
• container memory pressure
• Redis restart terlihat memperbaiki sementara

Likely causes:

• allocate/delete churn
• big key mutation
• persistence rewrite
• allocator behavior

Mitigation:

• reduce churn
• avoid huge mutable structures
• schedule maintenance if needed
• tune platform-level settings with SRE

31.3 No-Expiry Key Growth

Symptoms:

• key count terus naik
• memory naik linear dengan traffic
• expired_keys rendah

Likely causes:

• TTL tidak dipasang
• error path melewati expire
• idempotency/session/limiter key permanen

Mitigation:

• enforce TTL wrapper
• add test for TTL
• add key audit
• migrate/delete old keys safely

31.4 Stream Retention Failure

Symptoms:

• stream length naik terus
• PEL naik
• worker lag naik
• memory naik

Likely causes:

• missing XTRIM
• consumer tidak ACK
• worker crash
• retry loop

Mitigation:

• fix ACK path
• claim stale messages
• set retention
• add DLQ-like flow
• throttle producers

32. Memory Review Checklist

Saat review Redis memory design:

• Berapa expected key count?
• Berapa average dan p95 value size?
• Apakah semua ephemeral key punya TTL?
• Apakah TTL dipasang secara atomic dengan write?
• Apakah ada TTL jitter?
• Apakah ada upper bound untuk list/set/hash/zset/stream?
• Apakah eviction policy cocok dengan use case?
• Apakah cache dan correctness-critical key dicampur?
• Apakah stream punya retention?
• Apakah limiter sorted set punya cleanup?
• Apakah idempotency response payload terlalu besar?
• Apakah key name terlalu panjang?
• Apakah big key detection tersedia?
• Apakah memory dashboard punya alert yang actionable?
• Apakah capacity planning memasukkan growth dan failure headroom?

33. Internal Verification Checklist

Cek di codebase, Redis config, dashboard, dan diskusi team:

• maxmemory per environment.
• eviction policy per Redis instance.
• used_memory, RSS, fragmentation trend.
• key count trend.
• expired key dan evicted key trend.
• top prefixes by memory jika tooling tersedia.
• big key detection method.
• hot key detection method.
• TTL compliance untuk cache/idempotency/session/limiter/lock.
• stream length dan pending entries.
• rate limiter key cardinality.
• idempotency retention period.
• session/token memory model.
• Java serialization payload size.
• Kubernetes memory limit vs Redis maxmemory.
• AWS/Azure/on-prem memory metric and alert policy.
• runbook untuk memory pressure.
• incident notes terkait eviction/OOM/fragmentation.

34. PR Review Checklist

Saat review PR yang menambah Redis usage:

• Apakah PR menambah key baru?
• Apakah key punya owner dan lifecycle?
• Apakah TTL wajib dan diuji?
• Apakah value size bounded?
• Apakah data structure bounded?
• Apakah command dapat menghasilkan response besar?
• Apakah key cardinality dihitung?
• Apakah memory growth worst-case dihitung?
• Apakah eviction terhadap key ini acceptable?
• Apakah payload bisa dikurangi?
• Apakah key name terlalu panjang?
• Apakah ada observability untuk prefix baru?
• Apakah fallback path aman jika key evicted?
• Apakah Redis memory pressure bisa merusak PostgreSQL/Kafka/RabbitMQ path?

35. Senior Engineer Takeaway

Redis memory adalah correctness, performance, dan operational boundary.

Jangan hanya bertanya:

Berapa TTL-nya?

Tanyakan juga:

Berapa cardinality-nya, berapa payload size-nya, apa upper bound-nya, apa yang terjadi saat eviction, dan siapa yang menerima impact saat memory pressure?

Mental model akhir:

Redis memory = data model × access pattern × lifecycle discipline × operational headroom

Redis yang cepat dapat menjadi lambat bukan karena Redis buruk, tetapi karena aplikasi memperlakukannya seperti memory tak terbatas.