Redis/ElastiCache platform caching across serverless apps.

A shared cache gets risky when every service wires it differently.

The useful platform layer is small, but it needs a clear boundary.

• Hand-wire Redis in every app

  Fast for the first service, but it spreads endpoint, secret, and client-shape decisions across every downstream stack.

• Share one broad credential

  Easy to connect, but the blast radius is too large and cache key ownership becomes hard to reason about.

• Use a service-scoped platform pattern Chosen

  The chosen shape: shared cache foundation, generated service credentials, keyspace-scoped access, and repeatable app wiring.

• Build a central cache API

  Useful later if cache behavior becomes a product capability, but too much ownership shift for this infrastructure problem.

One shared cache foundation, service-level access around it.

The platform stack owns cache infrastructure and the exported endpoint and user-group identifiers. Each application stack owns its Redis user, generated secret, Lambda permission, runtime client, and cache behavior. That keeps reuse in the infrastructure layer without taking application ownership away.

• ElastiCache Serverless cache foundation
• Redis user group and service user membership
• Generated service secret payload
• SSM-style exports for endpoint and user-group identifiers
• Lambda runtime configuration from REDIS_SECRET_ARN
• Scoped secret-read grant for the consuming function
• Health-check and cleanup steps for app migration

The TypeScript surface keeps the moving parts named.

The companion repo is not a full CDK construct library. It is a typed model of the decisions that mattered: shared cache exports, service-scoped access, idempotent user planning, and Lambda runtime configuration.

export function createCachePlatformPlan(input: CachePlatformPlanInput): CachePlatformPlan {
  const selectedSubnets = [...new Set(input.subnetIds ?? [])].slice(0, 3);
  if (selectedSubnets.length < 2) {
    throw new Error("ElastiCache Serverless needs at least 2 subnets");
  }

  const endpoint = buildCacheEndpoint(input);
  const userGroupId = `${input.stage}-${normalizeService(input.serviceName)}-redis-users`;

  return {
    cache: {
      engine: "redis",
      name: `${input.stage}-${normalizeService(input.serviceName)}`,
      port: 6379,
      subnetIds: selectedSubnets,
      securityGroupIds: input.securityGroupIds ?? [],
      userGroupId
    },
    exports: {
      endpoint,
      userGroupId,
      userGroupArnParameter: `/platform/${input.stage}/${input.region}/redis/default/userGroupArn`,
      endpointParameter: `/platform/${input.stage}/${input.region}/redis/default/endpoint`
    }
  };
}

export function createRedisUserPattern(input: RedisUserPatternInput): RedisUserPattern {
  const secret = createServiceSecret(input);

  return {
    secretName: `/services/${normalizeKeyspace(input.serviceName)}/redis/${secret.keyspace}`,
    secret,
    user: {
      userId: secret.username,
      username: secret.username,
      accessString: buildAccessString(secret.keyspace)
    },
    userGroupMembership: {
      userGroupId: input.userGroupId,
      userIdsToAdd: [secret.username]
    }
  };
}

export function planRedisUserChange(input: PlanRedisUserChangeInput): RedisUserAction[] {
  const username = normalizeServiceUser(input.serviceName);
  const accessString = buildAccessString(input.keyspace);
  const userExists = (input.existingUsers ?? []).some(
    (user) => user.userId === username || user.username === username
  );
  const isInGroup = (input.currentGroupUserIds ?? []).includes(username);
  const actions: RedisUserAction[] = [];

  actions.push(userExists
    ? { type: "modify-user", userId: username, passwords: [input.password], accessString }
    : { type: "create-user", userId: username, username, engine: "redis", passwords: [input.password], accessString }
  );

  if (!isInGroup) {
    actions.push({ type: "add-user-to-group", userId: username });
  }

  return actions;
}

export function createRedisConnectionConfig(secret: RedisSecret): RedisConnectionConfig {
  for (const field of ["host", "port", "username", "password"] as const) {
    if (secret[field] === undefined || secret[field] === "") {
      throw new Error(`Redis secret is missing ${field}`);
    }
  }

  return {
    url: buildRedisUrl(secret),
    username: secret.username,
    password: secret.password,
    keyPrefix: secret.keyspace ? `${secret.keyspace}:` : "",
    socket: {
      tls: secret.tls !== false,
      checkServerIdentity: false
    }
  };
}

The adoption path matters as much as the cache.

A shared platform pattern only helps if application teams can adopt it without guessing which permissions, secrets, health checks, and cleanup steps are required.

1. 01

   Create the service Redis user and generated secret.

2. 02

   Inject REDIS_SECRET_ARN into the consuming Lambda environment.

3. 03

   Grant the Lambda role read access to only that Redis secret.

4. 04

   Build the Redis client from host, port, username, password, and keyspace.

5. 05

   Add a Redis ping or cache-read signal to the service health path.

6. 06

   Remove old Redis configuration after the deployment is stable.

The tests cover the provisioning behavior that is easy to drift.

The local tests check the behavior without deploying AWS resources or connecting to Redis. That makes the public sample deterministic while still showing what would matter in a real platform implementation.

test("plans user creation and group membership for new service user", () => {
  const actions = planRedisUserChange({
    serviceName: "enrollment-api",
    keyspace: "enrollment-api",
    password: "secret",
    existingUsers: [],
    currentGroupUserIds: []
  });

  assert.deepEqual(actions.map((action) => action.type), [
    "create-user",
    "add-user-to-group"
  ]);
});

What this design chooses, and what it does not claim.

1. 01

   Provisioning becomes explicit

   Per-service Redis users add a provisioning step. I prefer that cost here because credential rotation, group membership, and access changes become reviewable instead of manual.

2. 02

   Keyspace isolation is a boundary, not authorization

   Redis access strings and key prefixes reduce accidental collisions. They do not replace application authorization, so the service still owns what it caches and who can read it.

3. 03

   A caching boundary, not a datastore of record

   This is low-latency shared cache access. It is close to online serving, but it does not promise freshness guarantees or consistency between a cache and a source of truth. The service still owns what is safe to cache and for how long.

4. 04

   The public repo is intentionally local

   The companion repository does not deploy AWS resources. It keeps the behavior deterministic so the pattern can be evaluated without account IDs, secrets, or employer implementation details.