Clean Core Architecture Guide #52

SAP BTP Redis Distributed Caching & Locking in Clean Core Guide

⏱️ 14 min read 🏢 Enterprise Architectural Blueprint 🔒 Production Concurrency Control

Core Architectural Mandate: In high-throughput SAP Clean Core architectures, multiple side-by-side Cloud Foundry app instances and Kyma Kubernetes pods execute concurrently. Delegating concurrency control entirely to S/4HANA core enqueue locks causes severe lock collisions (HTTP 423), update task crashes, and database queue exhaustion. SAP BTP Redis provides an in-memory distributed lock and caching tier that enforces single-writer mutual exclusion before invoking core ERP APIs.

1. The Distributed Lock Problem in Side-by-Side BTP Apps

In a monolithic on-premise system, developers used SAP Enqueue locks (e.g. ENQUEUE_E_ORDER). In a side-by-side architecture on SAP BTP, microservices scale horizontally across multiple availability zones.

Concurrency Pattern	S/4HANA Enqueue Only	BTP Redis Redlock Tier
Lock Verification Latency	50ms - 200ms roundtrip to S/4HANA DB	0.4ms in-memory verification in BTP
High-Concurrency Bursts	SAP Enqueue server exhaustion; HTTP 423 exceptions	Smooth queued backoff at the BTP perimeter
Idempotency Enforcement	Core table duplicate check on every write	Atomic Redis Key check (zero database reads)
Deadlock Recovery	Manual unlock via SM12 by Basis administrator	Guaranteed TTL expiration (automatic release)

2. Implementing Redlock on SAP BTP

The Redlock algorithm guarantees mutual exclusion across distributed nodes without single points of failure:

// Atomic Lock Acquisition with Millisecond Precision
SET lock:salesorder:1000452 <unique_random_token> NX PX 10000

// Safe Lua Script Lock Release:
if redis.call("get", KEYS[1]) == ARGV[1] then
  return redis.call("del", KEYS[1])
else
  return 0
end

By passing a cryptographically secure random token (e.g. UUID v4) as the lock value, the client ensures that it only deletes its own lock and never prematurely releases a lock acquired by another pod that timed out.

Master High-Availability SAP BTP Architecture

Explore complete production blueprints for distributed caching, Redis session replication, CAP multi-tenancy, and Clean Core API security in The SAP Enterprise Architecture Suite.

Get the Full Architecture Suite (FLASH80 - 80% Off) →

3. The Cache-Aside Pattern for S/4HANA Master Data

Master data entities (Customers, Vendors, Materials, Exchange Rates) change infrequently but are read tens of thousands of times per minute by consumer apps.

With the Cache-Aside (Lazy Loading) pattern:

The BTP microservice queries Redis: GET s4:product:MAT-100.
On a Cache Hit (< 1ms), the cached JSON payload is returned immediately.
On a Cache Miss, the service executes a Clean Core OData V4 call to S/4HANA, populates Redis with an expiration TTL (e.g. 1 hour), and returns the payload.
When a product is updated in S/4HANA, a native RAP CloudEvent (Product.Changed.v1) is published to SAP Advanced Event Mesh (AEM), which evicts the stale Redis key.

4. Sliding Window Rate Limiting

To prevent denial-of-service spikes against S/4HANA core systems during flash sales or automated partner script runs, the BTP gateway deploys a Redis Sliding Window Rate Limiter using Redis Sorted Sets (ZSET):

// Record timestamp of current request
ZADD ratelimit:client_ip <current_timestamp> <request_id>

// Remove entries older than 60 seconds
ZREMRANGEBYSCORE ratelimit:client_ip 0 (<current_timestamp> - 60000)

// Count remaining requests in window
ZCARD ratelimit:client_ip

Summary Architectural Checklist

✅ Random Lock Tokens: Always verify lock ownership in Lua before deletion.
✅ Strict TTLs: Never create persistent locks without expiration.
✅ Event-Driven Invalidation: Invalidate cache keys using SAP AEM CloudEvents.
✅ Idempotency Guard: Store request UUIDs for 24 hours to prevent duplicate writes.

← Back to Interactive Redis Lock Architect Tool