feat(plugins): kv cache plugin

[maxktz]

ability to cache entitlements in a KV like for usage billing, for faster fetching of .check and .report

- Redis
- In memory kv
- Vercel KV

ability to configure the cache batching quantity, either TTL, or request batching

[linear]

PAY-167

[tedbrine]

I'm building a simple implementation, would love some thoughts

Firstly I don't think making it a plugin would be that good since it is tightly coupled with the database logic. Here is a proposal for what the config could look like with the types:

interface PayKitOptions {
  // ...
  secondaryStorage?: {
    get(key: string): Promise<string | null | undefined>;
    set(key: string, value: string, ttl?: number): Promise<void>;
    delete(key: string): Promise<void>;
    ttl?: number // seconds
  }
  // ...
}

This is very similar to how Better-Auth do it.

Read behavior:

• Checks secondary storage first
• If not found, queries the database
• Automatically populates secondary storage when falling back to database
• Ensures frequently accessed keys stay in cache over time

Write behavior:

• Writes to both database and secondary storage
• Ensures consistency between both storage layers

This style of config allows for the end user to make a decision on what kind of KV they use. For redis, it's pretty much a one liner going redis.get, redis.set, etc.

[maxktz]

@t3duk Thank you for taking action on that bro, this is a pretty complex domain logic, I haven't thought much on that, but I will dive deeper into thinking about that a bit later!

• Regarding the plugin, yeah, it's probably better to keep it in core, not a plugin.
• Good idea to use better-auth as a reference
• I think Autumn has a similar solution, Redis-only, you can use them as a reference as well

overall, it's important, but not high-priority right now, it's useful for bigger scaling, but we don't have much high-scale users yet

[maxktz]

@t3duk If you want you can drop a draft PR, I'll look into that and help with implementation👀