Ratelimiter: Refactor Storage Selection to Use Factory Pattern

[simzzz]

Problem

Problem

Storage selection logic lives in service classes instead of being encapsulated in factory methods. Services shouldn't know about storage implementation details.

Similar to the PendingTransactionStorage refactoring, we have other components with this pattern:

Rate Limit Store in IPRateLimiterService

private determineStoreType(): RateLimitStoreType { ... }
private createStore(storeType: RateLimitStoreType, duration: number): RateLimitStore {
  switch (storeType) {
    case RateLimitStoreType.REDIS:
      return new RedisRateLimitStore(this.logger, duration, this.rateLimitStoreFailureCounter);
    case RateLimitStoreType.LRU:
      return new LruRateLimitStore(duration);
  }
}

Solution

Solution

Add factory methods following the PendingTransactionStorageFactory pattern:

export class RateLimitStoreFactory {
  static create(logger: Logger, duration: number, counter?: Counter): RateLimitStore {
    const storeType =
      ConfigService.get('IP_RATE_LIMIT_STORE') ||
      (ConfigService.get('REDIS_ENABLED') ? RateLimitStoreType.REDIS : RateLimitStoreType.LRU);

    return storeType === RateLimitStoreType.REDIS
      ? new RedisRateLimitStore(logger, duration, counter)
      : new LruRateLimitStore(duration);
  }
}

// In Service
const store = RateLimitStoreFactory.create(this.logger, duration, this.counter);

Benefits

• Encapsulates storage selection logic where it belongs
• Services stay focused on orchestration
• Easier to add new storage types
• Consistent with existing patterns

Acceptance Criteria

• Factory methods created for components with storage selection logic
• Services updated to use factories
• Tests passing

Alternatives

No response