Project Refactoring: Service Integration with Redis

Previously in this course, we explored modularizing the cache service and implemented atomic rate limiting with Lua. While modular components are excellent for development, keeping them as separate, disconnected objects often leads to duplicate connection logic and fragmented dependency management.

In this lesson, we will perform a critical project refactoring to integrate these services into a single, unified RedisService. This architecture centralizes your connection pooling, simplifies your dependency injection, and streamlines the application startup flow.

Why Integrate Your Services?

As your project grows, maintaining separate instances for every Redis feature—caching, rate limiting, and session management—creates unnecessary overhead. Each service requires its own initialization logic, connection monitoring, and error handling. By consolidating these into a single service layer, you achieve:

1. Connection Efficiency: You share a single, optimized connection pool across all features.
2. Simplified Lifecycle: One point of entry for startup and graceful shutdown.
3. Dependency Clarity: Your controllers depend on one RedisService rather than a collection of dispersed modules.

Architectural Integration Pattern

We will build a wrapper that exposes specific methods for cache and rate-limiting operations. This acts as a "facade" pattern, hiding the underlying Redis commands while providing a developer-friendly interface.

Worked Example: The Unified RedisService

First, let's create RedisService.js. This class will manage the connection and provide access to both the caching and rate-limiting logic we've built throughout this course.

JAVASCRIPT
// src/services/RedisService.js
const { createClient } = require(CE9178">'redis');

class RedisService {
  constructor() {
    this.client = createClient();
    this.client.on(CE9178">'error', (err) => console.error(CE9178">'Redis Client Error', err));
  }

  async connect() {
    await this.client.connect();
  }

  // Cache Logic
  async getCache(key) {
    return await this.client.get(key);
  }

  async setCache(key, value, ttl = 3600) {
    return await this.client.set(key, value, { EX: ttl });
  }

  // Rate Limiting Logic (using our Lua script)
  async checkRateLimit(key, limit, window) {
    const script = CE9178">`
      local current = redis.call("INCR", KEYS[1])
      if tonumber(current) == 1 then
        redis.call("EXPIRE", KEYS[1], ARGV[1])
      end
      return current
    `;
    return await this.client.eval(script, {
      keys: [key],
      arguments: [window.toString()]
    });
  }
}

module.exports = new RedisService();

By exporting an instance (new RedisService()), we ensure that the rest of the application uses the same connection pool throughout the lifecycle of the process.

Streamlining Startup Flow

With a unified service, your server.js or entry point becomes significantly cleaner. Instead of managing multiple connection promises, you interact with your central service directly.

JAVASCRIPT
// src/app.js
const redisService = require(CE9178">'./services/RedisService');

async function startServer() {
  try {
    await redisService.connect();
    console.log(CE9178">'Redis connected and services initialized.');
    
    // Start your API server here...
  } catch (err) {
    console.error(CE9178">'Failed to start:', err);
    process.exit(1);
  }
}

startServer();

Hands-on Exercise

1. Consolidate: Move your existing CacheService and RateLimiter logic into the new RedisService structure shown above.
2. Refactor: Update one of your existing API controllers to import the single RedisService instance instead of the individual modules.
3. Verify: Run your application and verify that both caching and rate limiting still function as expected by hitting a test route twice.

Common Pitfalls

• Re-initializing Connections: A common mistake is creating new RedisService() inside a middleware or route handler. This will leak memory and exhaust your database connection limit. Always export a singleton instance.
• Ignoring Connection States: Ensure your application does not accept traffic until the redisService.connect() promise resolves. If a request arrives before the connection is ready, your cache lookups will fail.
• Over-abstraction: Do not turn your service layer into a "God object" that holds every single business rule. It should primarily handle data access and command execution; keep complex business logic inside your controllers or domain services.

Frequently Asked Questions

Q: Should I use multiple Redis instances for different features? A: Generally, no. For most beginner and intermediate projects, one Redis instance is sufficient. Use different key namespaces (e.g., cache:user:123 vs ratelimit:ip:127.0.0.1) to keep data segregated.

Q: What happens if the RedisService loses the connection? A: Your service should include robust error handling in the connect method or a reconnection strategy using the client's built-in event listeners to ensure high availability.

Recap

In this lesson, we unified our architecture by merging disparate Redis modules into a central RedisService. We moved away from scattered dependencies, implemented a singleton pattern for cleaner connection management, and simplified the startup logic. This approach is essential for scaling a project while keeping the codebase maintainable and predictable.

Up next: We will leverage our integrated service to start Implementing Global API Metrics, tracking usage patterns across our entire application.