Memorystore Redis

Memorystore is Google’s managed Redis service. zop.dev provisions the instance with network access and an in-cluster DNS alias so applications connect by a stable service name.

A Redis instance, a firewall rule, and an alias

google_redis_instance (cluster or single), firewall rule, and a Kubernetes ExternalName service.

Tier, memory, replicas, and connect mode

tier BASIC|STANDARD (default BASIC); memory_size 1 GB; replica_count 1; connect_mode DIRECT_PEERING; redis_version REDIS_7_0.

Only BASIC and STANDARD are cataloged

Only BASIC and STANDARD tiers are cataloged for Memorystore.

BASIC restarts empty

The default tier is BASIC: one node, no replica. Maintenance windows, scaling operations, and failures all share one consequence: the instance comes back with nothing in it. For a true cache that repopulates from a database, a cold start is a latency blip and BASIC’s price is the right trade. For sessions, queues, rate-limit counters, or anything else that cannot be recomputed, STANDARD is the floor. It adds the replica and automatic failover that make a flush an event instead of a data loss. The tier choice is really a question about what the application put in Redis, and it deserves an explicit answer per environment.

Per-GB-hour, always on

Memorystore bills by provisioned capacity per hour: memory_size (1 GB default) times tier rate, continuously, idle or busy. STANDARD roughly doubles BASIC at the same size because the replica is a second node. Capacity can be grown later, so the cheap strategy is starting at the default and scaling on evidence rather than provisioning for a guess.

Two settings frozen at creation

connect_mode is permanent for the instance’s life, and DIRECT_PEERING is the value here. Moving to private-services-access networking means a new instance and a client cutover. redis_version (REDIS_7_0) upgrades forward but never back. Both are worth a deliberate glance before the first byte is cached, because both outlive every other setting.

The alias is the contract

The Kubernetes ExternalName service is what applications should connect to: a stable in-cluster name pointing at the instance’s endpoint, with the firewall rule admitting the traffic. Re-provisioning, resizing, or replacing the instance then becomes an alias update: zero application config changes, which is precisely what makes the fixed-at-creation settings above survivable.