Caching Strategy

Caching is employed in the LCFS system to improve performance, reduce latency, and decrease the load on backend services, particularly the database.

Backend Caching (backend service)

Based on the project dependencies (pyproject.toml), the backend service utilizes the following for its caching strategy:

• Redis: An in-memory data store (redis service in docker-compose.yml, redis Python library).
• FastAPI Cache 2 (fastapi-cache2): This library is used to integrate Redis caching directly with FastAPI endpoints. It likely provides decorators or utilities to cache responses from specific API routes.

How it Works (Inferred)

1. Endpoint Caching: Specific API endpoints that serve frequently accessed and relatively static data are likely decorated or configured using fastapi-cache2.
2. Cache Key Generation: When a request hits a cached endpoint, a cache key is generated, typically based on the request path and query parameters.
3. Cache Lookup: The system checks Redis for an existing entry associated with this key.
   • Cache Hit: If a valid (non-expired) entry is found, the cached response is served directly, bypassing the actual endpoint logic and database queries.
   • Cache Miss: If no entry is found or the existing entry has expired, the request proceeds to the endpoint logic. The response generated by the endpoint is then stored in Redis with the generated key and a defined Time-To-Live (TTL).

Types of Data Cached (Potential)

• Responses from GET requests for data that doesn't change frequently.
• Computed results or aggregations that are expensive to calculate.
• Configuration data or lookup tables.

Cache Invalidation

• TTL (Time-To-Live): The primary mechanism for cache invalidation is likely based on TTLs set for cache entries. Once the TTL expires, the cached data is considered stale, and the next request will fetch fresh data.
• Event-Driven Invalidation (Potential): For more dynamic data, there might be mechanisms to explicitly invalidate cache entries when underlying data changes (e.g., after a PUT, POST, or DELETE request modifies a resource). This would require custom logic in the backend.

Frontend Caching

• Browser Caching: Standard HTTP caching headers (e.g., Cache-Control, ETag, Expires) set by the backend or the web server serving the frontend assets will be utilized by browsers to cache static assets (JS, CSS, images) and potentially API responses.
• Client-Side State Management: The frontend framework (to be identified by inspecting frontend/) might have its own in-memory caching or state management solutions that cache data fetched from APIs to avoid redundant requests during a user session.

Further Investigation

• Review backend code (specifically FastAPI routes and fastapi-cache2 configurations) to identify which specific endpoints are cached and their TTLs.
• Examine backend logic for any custom cache invalidation strategies.
• Analyze HTTP headers returned by the backend and frontend servers to understand browser caching configurations.
• Investigate the frontend codebase for client-side caching mechanisms.