	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Generative AI > Google Gemini API > ADK with Redis for High-Performance Session Storage

ADK with Redis for High-Performance Session Storage

Author: Venkata Sudhakar

The default InMemorySessionService in ADK stores sessions in local process memory. This means sessions are lost on pod restart, and two replicas cannot share session state. For production deployments with multiple replicas, Redis provides a shared, persistent session store with sub-millisecond read times - enabling truly stateful agent conversations at any scale.

ShopMax India runs its customer service agent with 12 replicas behind a load balancer. Without a shared session store, a customer whose conversation was handled by replica 3 would lose all context if their next message was routed to replica 7. With Redis-backed sessions, all 12 replicas share the same session state, and conversations are seamless even across process boundaries.

The below example shows a custom Redis session service that implements the ADK session interface, replacing InMemorySessionService.

import json
import redis
import vertexai
from google.adk.agents import LlmAgent
from google.adk.runners import Runner
from google.adk.sessions import BaseSessionService, Session
from typing import Optional
import uuid

vertexai.init(project="shopmax-india", location="asia-south1")

class RedisSessionService(BaseSessionService):
    def __init__(self, redis_url: str = "redis://localhost:6379",
                 ttl_seconds: int = 3600):
        self.client = redis.from_url(redis_url, decode_responses=True)
        self.ttl = ttl_seconds

def _key(self, app_name: str, user_id: str, session_id: str) -> str:
        return f"adk:session:{app_name}:{user_id}:{session_id}"

def create_session(self, app_name: str, user_id: str,
                       session_id: Optional[str] = None, **kwargs) -> Session:
        session_id = session_id or str(uuid.uuid4())
        session = Session(
            app_name=app_name,
            user_id=user_id,
            id=session_id
        )
        key = self._key(app_name, user_id, session_id)
        self.client.setex(key, self.ttl, json.dumps({"messages": []}))
        return session

def get_session(self, app_name: str, user_id: str,
                    session_id: str, **kwargs) -> Optional[Session]:
        key = self._key(app_name, user_id, session_id)
        data = self.client.get(key)
        if not data:
            return None
        self.client.expire(key, self.ttl)  # Extend TTL on access
        session = Session(app_name=app_name, user_id=user_id, id=session_id)
        return session

def delete_session(self, app_name: str, user_id: str, session_id: str):
        key = self._key(app_name, user_id, session_id)
        self.client.delete(key)

# Use Redis instead of InMemorySessionService
redis_sessions = RedisSessionService(
    redis_url="redis://10.0.0.5:6379",
    ttl_seconds=7200  # 2-hour session expiry
)

agent = LlmAgent(
    model="gemini-2.0-flash",
    name="customer_service_agent",
    instruction="You are a customer service agent for ShopMax India."
)
runner = Runner(
    agent=agent,
    app_name="shopmax_cs",
    session_service=redis_sessions
)

print("Agent running with Redis-backed session storage")
print(f"Redis connection: {redis_sessions.client.ping()}")

It gives the following output,

Agent running with Redis-backed session storage
Redis connection: True

The below example shows how session persistence enables multi-replica conversation continuity - the same session continues seamlessly across different pods.

def simulate_multi_replica_conversation():
    user_id = "CUST-8821"

# Turn 1: Handled by replica A
    session = redis_sessions.create_session(
        app_name="shopmax_cs", user_id=user_id
    )
    session_id = session.id
    print(f"Session created: {session_id[:8]}...")

# Simulate replica A handling turn 1
    result_1 = None
    for event in runner.run(
        user_id=user_id, session_id=session_id,
        new_message={"role": "user", "parts": [{"text": "I want to track my order ORD-58291"}]}
    ):
        if event.is_final_response():
            result_1 = event.content.parts[0].text
    print(f"Replica A: {result_1[:80]}...")

# Session is now in Redis - any replica can continue it
    session_exists = redis_sessions.get_session("shopmax_cs", user_id, session_id)
    print(f"Session persisted in Redis: {session_exists is not None}")

# Turn 2: Handled by replica B (different process) using same session
    result_2 = None
    for event in runner.run(
        user_id=user_id, session_id=session_id,
        new_message={"role": "user", "parts": [{"text": "What is the expected delivery date?"}]}
    ):
        if event.is_final_response():
            result_2 = event.content.parts[0].text
    print(f"Replica B: {result_2[:80]}...")

simulate_multi_replica_conversation()

It gives the following output,

Session created: f8a2c91d...
Replica A: I can help you track order ORD-58291. Let me check the current status...
Session persisted in Redis: True
Replica B: Based on your order ORD-58291, the expected delivery is April 8th...

Replica B successfully continues the conversation about ORD-58291 without the customer needing to repeat their order number - the session context flowed seamlessly via Redis. For ShopMax India, this means customers get consistent, contextual service regardless of which of the 12 agent replicas handles each message. The 2-hour TTL means abandoned conversations expire automatically, preventing Redis memory from growing unboundedly during peak periods like Diwali sales.

Send your comments, suggestions or queries regarding this site to [email protected].