Cache Informix reads in Redis, and invalidate from inside the engine.
An Informix and Redis integration that reads and writes the cache from ordinary SQL and SPL, invalidates the exact key a trigger knows changed, and streams committed row changes to Redis for durable cache sync. The database stays the system of record; Redis carries the read pressure. Two planes — a synchronous in-engine call-out and an asynchronous change stream — proven on IBM Informix 14 and 15.
Cache-aside from ordinary SQL
The cache is read and written with plain functions in a query — redis_set, redis_get, redis_setex with a TTL, redis_del. No application relay stands between the database and the cache.
Invalidation lives on the table
A trigger deletes exactly the key whose row changed, in the same statement that changed it. The cache cannot be left stale by a code path that forgot to invalidate, because the code path no longer owns the invalidation.
Two planes, one convention
A synchronous plane calls Redis inline from SQL, SPL and triggers; an asynchronous plane streams committed row changes to Redis for durable sync. Both publish through the same client core, so keys and behaviour are identical.
Degrades, does not stall
A Redis outage is bounded by a short connect timeout and a process-global cooldown, so calls short-circuit instead of paying the timeout on every statement. A failed cache call never rolls back the user's transaction.
Two planes to Redis
Why cache invalidation belongs in the database
The recurring failure of a cache beside a database is not the cache — it is keeping the two in step. When application code owns the invalidation, a write path that updates a row but forgets to evict its cached copy serves stale data indefinitely. Two application servers that each "remember to update Redis" eventually disagree. An event published before its transaction commits is a phantom that never happened.
Moving the Redis interaction inside the database, next to the business data, removes that class of bug. A trigger invalidates exactly the cache key whose row changed; a counter is incremented in the same logical step as the insert that earned it; a cache-sync feed is derived from the committed log rather than from hopeful application code. The database becomes the single writer of cache events, so there is no second copy of the invalidation logic to drift out of step.
How the cache integration works
From a query, a trigger, or the committed log. Informix remains the source of truth; Redis carries the reads.
Cache-aside from SQL and SPL
The Redis string commands are exposed as functions — redis_set / redis_get, redis_setex to write with a TTL, redis_del to evict. A read checks Redis first and falls back to the table on a miss; a write refreshes or drops the key. The endpoint is configured once with redis_init and held in shared memory, so any routine server-wide can reach the cache without knowing the configuration.
Precise invalidation from a trigger
On every update the trigger runs redis_del on the one key that maps to the changed row — cache:order:1001, not the whole namespace. Because the call runs inside the statement, the cache can never be left stale by forgetful application code, and the invalidation fires no matter which code path performed the write.
Durable sync from the change stream
Where an outage must not touch the write path, a change-data-capture agent reads committed row changes from the Informix logical log and publishes each one to a Redis stream as a JSON envelope. A downstream cache, materialised view or search index applies those changes in order and refreshes the exact keys that moved — decoupled from the transaction that produced them.
Where Informix stays the system of record
Redis holds a copy for speed; the committed database holds the truth. The synchronous plane is deliberately best-effort — a failed cache call returns an error string or a sentinel but does not abort the transaction — so the record of the business fact is always the row that committed, never the cache entry.
Bounded failure, automatic recovery
A connect attempt is bounded to 1.5 seconds and tried three times; after a failure a five-second process-global cooldown makes further calls short-circuit, so a Redis outage does not add latency to every statement. When Redis returns, the cooldown expires and the next call reconnects — no operator action, no manual failover.
Fail-open or fail-closed, your choice
The integer-returning functions return -1 when Redis is unreachable, distinct from a legitimate 0. So a caller decides explicitly whether a cache or coordination check fails open — serve on, treat Redis as advisory — or fails closed, rather than having the behaviour decided for it.
An application-managed cache vs the Informix Redis integration
| An application-managed cache | The Informix Redis integration | |
|---|---|---|
| Where invalidation lives | Scattered across every code path that writes a row — each must remember to evict | ✓ On the table, in a trigger that fires in the same statement as the write |
| A forgotten eviction | Leaves stale data served indefinitely, until a TTL happens to expire it | ✓ Cannot occur — the code path no longer owns the invalidation |
| Multiple writers | Each application server updates Redis on its own; the copies drift apart over time | ✓ The database is the single writer of cache events; no copy to drift |
| What the cache trusts | Hopeful application code that can forget, race, or partially fail | ✓ The committed row change, or the committed logical log |
| Phantom events | An event can be published before its transaction commits, then never happens | ✓ None — the change stream is derived from committed transactions only |
| Durable cache sync | A bespoke relay to build, maintain and operate | ✓ The change-capture agent streams committed changes to Redis, at-least-once |
| System of record | Ambiguous in practice once the copies disagree | ✓ Always Informix; Redis is a copy for speed, never the truth |
What teams use it for
The cache surface, applied. Each pattern keeps Informix the source of truth and takes read pressure off the engine.
Read offload with cache-aside
Serve hot rows from Redis and fall back to the table on a miss, with a TTL that bounds staleness. High-read keys — a product record, a customer profile, a price — are answered from memory, so the engine spends its cycles on the writes and the queries that genuinely need it.
Exact-key invalidation on write
Attach a trigger that evicts the cached key when its row changes. The cache reflects the committed state of the row it caches, and it does so without any application discipline to remember — the invalidation is a property of the table, not of the calling code.
Downstream cache and view sync
Feed a read replica, a search index or a materialised view from the change stream. Each committed change lands as a JSON envelope on a Redis stream in order, so consumers refresh or evict the precise keys that moved and never diverge from the source.
Safe consumers under at-least-once
Because the change stream delivers at-least-once, a consumer may see a change twice after a mid-publish restart. The redis_idempotent check — first-seen returns 1, a duplicate returns 0 — lets a cache-refresh or fulfilment worker dedupe on the change identity and apply each change once.
Before you put it in front of a production estate.
How does the cache stay consistent — what stops it serving stale data?
Invalidation runs where the write runs. A trigger calls redis_del on the exact key whose row changed, inside the statement that changed it, so no application code path can update a row and forget to evict its cached copy. This is best-effort by design: the cache call never rolls back the transaction, so on the rare occasion Redis is unreachable during a write, the eviction is missed and a TTL bounds how long the stale entry lives. Where staleness must never occur, drive the cache from the change stream instead — it derives from the committed log and refreshes keys after the fact, decoupled from the write path.
What happens when Redis is down?
A connect attempt is bounded to 1.5 seconds and tried three times; after a failure a five-second process-global cooldown makes subsequent calls return immediately without paying the connect timeout, so an outage does not add latency to every statement. The transaction is never aborted by a failed cache call — coupling a commit to an external system is exactly the risk the change-stream plane exists to avoid. Recovery is automatic: when Redis returns the cooldown expires and the next call reconnects, with no operator action. The integer-returning functions return -1 when Redis is unreachable, so a caller can choose to fail open or fail closed explicitly.
Is Informix still the system of record?
Yes, without qualification. Redis holds a copy for speed; the committed database holds the truth. The synchronous cache functions are best-effort and never abort a transaction, and the change stream is derived from the committed logical log — so the record of a business fact is always the row that committed, and the cache is only ever a projection of it.
What runs inside the engine, and what runs outside it?
The synchronous cache and coordination functions run inside the engine as user-defined routines, called from SQL, SPL and triggers. The change-capture agent runs outside the engine as a standalone process, because the Informix change-capture interface cannot be called from a user-defined routine. Both publish through the same Redis client core, so key conventions and behaviour are identical across the two planes.
When do I invalidate synchronously, and when do I stream?
Use the synchronous trigger when you want the exact key evicted the instant its row changes and can accept a best-effort call bounded by the connect timeout. Use the change stream when an outage must not touch the write path at all, or when several downstream copies — a cache, a search index, a view — must be kept in step durably. The synchronous plane couples the statement to Redis availability, bounded but never zero; the streamed plane decouples it entirely at the cost of asynchronous delivery.
What are the delivery guarantees on the change stream, and its limits?
Delivery is at-least-once. The agent does not advance its log position past an unpublished change, so nothing committed is lost, but a change may be re-published after a mid-publish restart — consumers must be idempotent, which is what redis_idempotent is for. One honest limit: a persistent log-position checkpoint across agent sessions is a planned refinement. Today a restart resumes from the current log position, so changes made while the agent was down between sessions are not back-filled — run it under a supervisor to minimise the gap, and size the logical logs for the worst-case downtime, exactly as you would for Enterprise Replication.
How is the Redis connection secured and configured?
The endpoint — host, port and an optional password for Redis AUTH — is set once with redis_init and held in Informix shared memory, so every routine server-wide reaches the same authenticated cache without embedding credentials. The shared-memory endpoint is lost on an engine shutdown, so redis_init is re-run at startup, for example from a scheduled task. The change-capture agent connects to the engine with authenticated credentials over TCP and writes to the same Redis endpoint.
Which Informix versions is it proven on?
Informix 14 and 15. The synchronous cache and coordination functions pass a full live test suite, and the change-capture bridge is verified against six real-scenario tests that assert the exact JSON landing on Redis — including lossless fixed-scale DECIMAL, 64-bit BIGINT, ISO-8601 DATETIME, SQL NULL as JSON null, and injection-safe escaping of arbitrary user text.