Add caching layer for repeated PURL metadata queries

[Shalini828]

Problem : -

Currently, PurlDB processes repeated queries for the same PURL without any caching mechanism. This leads to redundant database/API calls, especially during large-scale operations such as SBOM imports or repeated metadata lookups.

Proposed Solution :-

Introduce a caching layer to store frequently accessed PURL metadata. This could include:

• In-memory caching (e.g., LRU cache)
• Optional Redis-based caching for scalability
• Cache invalidation strategy when data updates

The caching should be applied to:

• metadata queries
• version lookups
• URL retrieval functions

Benefits :-

• Improved performance for repeated queries
• Reduced database/API load
• Faster SBOM processing
• Better scalability for large datasets

Additional Context :-

Similar issues around repeated metadata access and inefficiencies have been observed in related tools interacting with PurlDB. Adding caching would improve overall system responsiveness and usability.

[Shalini828]

Hi, I am exploring PurlDB for GSoC 2026. I noticed this potential performance improvement and wanted to get feedback from maintainers on whether this would be a useful feature. I would be happy to work on it if it aligns with the project goals.