feat: add cache factory, unify client interface, remove fallback (#4558)

[jasuwienas]

Description

1. The Cache Client creation process has been moved into a dedicated factory.
2. A single, unified client interface is now used instead of separate interfaces for each client (IRedisClient and IClient).
3. The fallback mechanism has been removed from the cache service, along with all conditions determining which client to use - the service now relies on a single client.
4. Most of the changes are in the tests. Since the cache service creation method has been updated, all test cases that instantiate it now follow the new logic.

Related issue(s)

Fixes #4558

Testing Guide

1. Run all tests with debug mode on WITHOUT this tasks changes applied.
2. Make sure they all pass.

Changes from original design (optional)

Additional work needed

The Redis cache service still implements an additional, unnecessary interface and only measures logs and delegates calls to the underlying client. It will be removed entirely in this PR.

Checklist

• I've assigned an assignee to this PR and related issue(s) (if applicable)
• I've assigned a label to this PR and related issue(s) (if applicable)
• I've assigned a milestone to this PR and related issue(s) (if applicable)
• I've updated documentation (code comments, README, etc. if applicable)
• I've done sufficient testing (unit, integration, etc.)

[codecov]

Codecov Report

❌ Patch coverage is 96.25780% with 18 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...kages/relay/src/lib/clients/cache/localLRUCache.ts	90.32%	6 Missing ⚠️
...ckages/relay/src/lib/clients/cache/ICacheClient.ts	0.00%	5 Missing ⚠️
...kages/relay/src/lib/clients/cache/fallbackCache.ts	97.74%	4 Missing ⚠️
...elay/src/lib/services/cacheService/cacheService.ts	0.00%	3 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (c004a57) and HEAD (db14ae9). Click for more details.

HEAD has 20 uploads less than BASE

Flag	BASE (c004a57)	HEAD (db14ae9)
	19	1
ws-server	1	0
server	1	0

@@            Coverage Diff             @@
##             main    #4623      +/-   ##
==========================================
- Coverage   95.48%   86.95%   -8.54%     
==========================================
  Files         129      131       +2     
  Lines       20903    20938      +35     
  Branches     1782     1482     -300     
==========================================
- Hits        19959    18206    -1753     
- Misses        924     2682    +1758     
- Partials       20       50      +30     

Flag	Coverage Δ
config-service	98.83% <ø> (ø)
relay	90.98% <96.25%> (+0.06%)	⬆️
server	?
ws-server	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ges/relay/src/lib/clients/cache/measurableCache.ts	100.00% <100.00%> (ø)
packages/relay/src/lib/clients/cache/redisCache.ts	89.78% <100.00%> (-4.35%)	⬇️
...ages/relay/src/lib/factories/cacheClientFactory.ts	100.00% <100.00%> (ø)
packages/relay/src/lib/relay.ts	94.15% <100.00%> (-4.50%)	⬇️
...elay/src/lib/services/cacheService/cacheService.ts	0.00% <0.00%> (-97.50%)	⬇️
...kages/relay/src/lib/clients/cache/fallbackCache.ts	97.74% <97.74%> (ø)
...ckages/relay/src/lib/clients/cache/ICacheClient.ts	0.00% <0.00%> (ø)
...kages/relay/src/lib/clients/cache/localLRUCache.ts	91.56% <90.32%> (-2.15%)	⬇️

... and 44 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[quiet-node]

@jasuwienas Nice work it's a big one! However, The issue #4558 seems to ask for a fairly simple change: adding a CacheFactory to choose between RedisCache and LocalCache, right? That would make it consistent with PendingTransactionStorageFactory, the upcoming LockStrategyFactory, and IPRateLimiterFactory. But this PR seems to include a lot more than that.

I’m also seeing things like MeasureCache and FallbackCache, which look like new concepts. Have we had a design session as a team about these changes? I’m just wondering if we’re adding more complexity than needed for what was supposed to be a straightforward technical-debt fix.

[jasuwienas]

@quiet-node Right, I'll prepare an ADR.

to choose between RedisCache and LocalCache

Not exactly. Our current implementation works like this:

1. We first attempt to communicate with the Redis client.
2. If it succeeds - great, we use Redis.
3. If it fails - we fall back to LRU.

This is precisely what the FallbackClient was originally designed to support.
I wanted to maintain a single ClientInterface returned by Factory (as required in the task) while keeping the existing fallback behavior unchanged.

With that approach, the factory would still return one unified client object with a consistent interface.

The alternative would be this: https://github.com/hiero-ledger/hiero-json-rpc-relay/pull/4628/files

the factory returns both the shared and internal clients here, allowing us to keep cacheService as it is.

Or this:

https://github.com/jasuwienas/hiero-json-rpc-relay/tree/4558-factory-for-cache-client-simplified-2

(we are calling the factory twice)

[jasuwienas]

Dropping the fallback mechanism is a breaking change! During review, please take a look at:
packages/relay/tests/lib/services/cacheService/cacheService.spec.ts
to see what has changed

[jasuwienas]

BTW. To investigate the retry strategy take a look at packages/relay/src/lib/client/redisClientManager.ts

I think we already have it covered there.