Implement caching for user admission check

[Mohit-Davar]

Description

This PR implements the TODO: use cache in EventMessageHandler by introducing a Redis-based caching layer for user admission status.

Key Implementation Details

• State-Aware Caching

  • Uses getKey to differentiate:
    • 1 → Admitted users
    • 0 → Blocked / insufficient balance
    • null → Cache miss

• TTL Strategy

  • Admitted users: 300s (5 minutes)
  • Blocked / low-balance users: 60s (1 minute)
  • Prevents database hammering while keeping data reasonably fresh

• Atomicity & Resilience

  • Uses a non-blocking cacheSet helper
  • Redis operations are async and do not impact event ingestion latency

• Testing

  • Updated event-message-handler.spec.ts with mock cache behavior

---

Related Issue

Resolves the caching TODO in:
src/handlers/event-message-handler.ts
#447

---

Motivation and Context

On high-traffic relays, performing database checks for every event introduces significant overhead.
This change:

• Reduces database load
• Improves event processing latency
• Enhances scalability under high throughput

---

How Has This Been Tested?

• Unit Tests
  • Updated test/unit/handlers/event-message-handler.spec.ts

---

Screenshots

N/A

---

Types of Changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (would cause existing functionality to change)

---

Checklist

• Code follows project style guidelines
• Documentation updated (if required)
• CONTRIBUTING guidelines reviewed
• Tests added/updated
• All tests passing

[Mohit-Davar]

Hi! @cameri While working on my PR fixes, I noticed the project has moved to Biome formatting.

When I ran npm run format, it reformatted a large number of files. I compared with origin/main and didn’t see these formatting changes there, so I’m not sure if this was intentional or if my local setup is applying a different Biome config/version.

Could you please confirm the expected workflow here?
Should I:

• keep these formatting changes as part of the PR, or
• revert them and only include my functional changes?

I just want to align with the repository’s preferred formatting approach.

[phoenix-server]

Hi @Mohit-Davar — only include your functional changes, not the mass formatting reformats. The Biome config in this repo is set to report warnings, not errors, so running npm run format reformats more than needed for a PR. Keep formatting changes scoped to lines you actually touched.

[coveralls]

coverage: 63.346% (+0.5%) from 62.807% — Mohit-Davar:cache into cameri:main

[cameri]

@Mohit-Davar let me know if that helps. I'm happy to merge with format fixes too.

[Mohit-Davar]

@Mohit-Davar let me know if that helps. I'm happy to merge with format fixes too.

Thanks, that helps, I appreciate the clarification!

I understand to keep formatting limited to the files or lines I modify instead of running a full repo format. I’ll follow that workflow in future PRs.