Caching Strategy

The MessageJS backend employs a multi-layered caching strategy to ensure high performance, low latency, and reduced load on the primary database. The strategy involves both an application-level cache using Redis and a database query cache provided by Prisma Accelerate. This dual approach optimizes different aspects of the system, from authenticating high-throughput API requests to accelerating general data retrieval.

This document outlines the architecture and components of the caching system as defined within the project's source files.

High-Level Architecture

MessageJS integrates two distinct caching layers between the client and the PostgreSQL database. Redis serves as a fast, in-memory cache for specific application logic, while Prisma Accelerate provides a managed caching layer for database queries.

The diagram below illustrates the data flow for a request through the caching layers.

Caching Components

Sources: README.md:43, packages/core/package.json:16, packages/core/src/api/middleware/authMiddleware.ts:40

Application-Level Caching (Redis)

The core backend architecture specifies Redis as the primary caching solution. It is intended for application-level optimizations where the logic can explicitly check for and store data in the cache.

Sources: README.md:43

Use Case: API Key Validation

A critical use case for Redis is caching the validation status of API keys. The validateApiKey middleware is designed to leverage Redis to avoid a database query on every incoming message request, which is crucial for performance and scalability.

The planned implementation flow is as follows:

1. An incoming request with an API key hits the validateApiKey middleware.
2. The middleware first checks Redis for the existence and validity of the key.
3. Cache Hit: If the key is found in Redis, its details (e.g., projectId) are attached to the request object, and the request proceeds immediately.
4. Cache Miss: If the key is not in Redis, the middleware queries the PostgreSQL database to validate the key.
5. Upon successful validation from the database, the key's details are stored in Redis for subsequent requests.
6. The request proceeds.

Sources: packages/core/src/api/middleware/authMiddleware.ts:36-40

The following sequence diagram illustrates this process.

The planned caching logic is documented in the middleware's source code:

// packages/core/src/api/middleware/authMiddleware.ts:36-40
  // --- Mock Implementation ---
  // In a real application, this section would involve:
  // 1. Hashing the provided `apiKey` if we store hashes.
  // 2. Querying the `APIKeys` table in the database for a matching key/hash.
  // 3. Checking if the key is active and belongs to an active project.
  // 4. Caching the result in Redis for performance.

Sources: packages/core/src/api/middleware/authMiddleware.ts:36-40

Database Query Caching (Prisma Accelerate)

The project utilizes @prisma/extension-accelerate, a powerful extension for Prisma Client that provides a managed, globally distributed cache for database queries. This acts as a transparent caching layer between the application and the PostgreSQL database.

Sources: packages/core/package.json:16

Functionality

Prisma Accelerate works by intercepting queries made by the Prisma Client.

• When a query is executed for the first time, it hits the PostgreSQL database (defined in docker-compose.yml and packages/core/prisma/schema.prisma), and the result is cached.
• Subsequent identical queries will be served directly from the Accelerate cache, significantly reducing response times and database load.
• It also manages cache invalidation automatically when data is mutated (created, updated, or deleted).

This caching is applied to all models defined in the Prisma schema, such as User, Project, Service, Template, and MessageLog.

Sources: packages/core/package.json:16, packages/core/prisma/schema.prisma

The diagram below shows the relationship between the Prisma Client, Accelerate, and the database.

Conclusion

MessageJS implements a robust, two-tier caching strategy to deliver a fast and reliable service. By using Redis for application-specific optimizations like API key authentication and leveraging Prisma Accelerate for broad database query caching, the architecture is designed to handle high-volume traffic efficiently. This approach minimizes latency for end-users and protects the underlying PostgreSQL database from excessive load, ensuring the system remains scalable and responsive.