NATS feed caching options

[theobouwman]

We want to improve our user/community feed system with some caching and are considering 2 options.

This is the structure of our feed table: itemId, userId, postId, eventId, eventType, communityId, timestamp.
And the json response will look something like:

{
  "feed": [
    {
      "itemId": "item1",
      "timestamp": "2024-04-08T12:00:00Z",
      "eventType": "new_post",
      "user": {
        "userId": "user123",
        "userName": "JaneDoe",
        "userProfilePicture": "profilePictureUrl"
      },
      "post": {
        "postId": "post456",
        "postTitle": "Exciting Event Coming Up!",
        "postContent": "Don't miss our next community event on April 20th.",
        "postImageUrl": "imageUrl"
      },
      "event": {
        "eventId": "event789",
        "eventName": "Community Meetup",
        "eventDate": "2024-04-20",
        "eventLocation": "Central Park"
      },
      "community": {
        "communityId": "comm1",
        "communityName": "Tech Enthusiasts",
        "communityDescription": "A community for tech lovers to share and discuss the latest in technology."
      }
    }
  ]
}

We don't want to fetch the feed from the database each time a user requests the feed since multiple join are used to fetch the post, event, user, etc. So we want to store it in the NATS kV cache somehow and directly access and return it to the user. In the coming months 15k-20k users will join our platform. So a robust, future proof and not that hard to implement and main solution will be preferred :)

So we thought of these options:

1. Cache latest 30 items in NATS KV as feed.communityid.0, latest 31-60 in feed.communityId.1 . This means updating feed.N on each feed item edit/delete etc.

2. Push all feed items to feed.communityId.itemId as regular messages and fetch latest 30 messages with pull push fetch() function? Is this fast enough? This does not allow paging/offset right?

3. Cache just the feed ids in the feed.communityId.feedItems KV. And store each feed item in the feed.community.items.itemId KV. Then for the API request we fetch the feedItems KV, and then for each in the feedItems KV we fetch the item from the feed.community.items.itemId KV. So a looped fetch. Probably not the best solution imo.

Which if these is the more go-to solution, or are we missing other options?

If some one knows any other caching solution which can be solved using NATS please let me know!

[ripienaar]

1. This is interesting and will be quick to read, but then updating each and moving the messages around could be costly, might some kind of time bracket based cache where messsages for minute 1-5 goes in a bucket, minute 6-10 in another etc, or maybe some other kind of bucketing where a message is essentially static once written till it ages out
2. fetch is fairly expensive because in this model I think you'd have to adjust filters and reset back to oldest message at some times right? this means recreating consumers etc. Ideally you do what can be done with the DIRECT GET API. We are doing some work on this especially around batches of messages, multiple subjects and more, it would be very beneficial to understand this API and deisgn something that your access is based on this. https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-31.md
3. This is interesting, your cache clients could Watch the ids bucket and maintain some local map and fetch only the data they need. I think this might also combine well enough with the 2nd option.

But assuming your lookup key is itemId I'd maybe just stuck them in cache.<itemId>, use the direct get API to get the one you want and if you get a key not exist go to the DB and store it using Create(). This way you can dynamically - even at runtime - adjust the cache retention options like age/count etc and clients will just keep working.

The benefit of this is also that as you grow you can build a cluster of servers or even a geo distributed super cluster. If you use JetStream to MIRROR the cache bucket to all your regions then automatically with no code changes the nearest (nats network latency wise) cache will be used for reads. Since the DIRECT GET API is mirror aware and will read from nearest bucket. You can, using leafnodes, even create local-to-the-node caches like this for a real big distributed cache so you can scale out the reads.

[nickchomey]

I dont have any insights about how to best use NATS for this, but it seems like you could benefit from reading about how existing platforms implement things like newsfeeds. Its a very well-trodden path. Just search for things like newsfeed system design, fan out on read/write, etc...

You could probably process each post upon creation and store it in a KV subject. Then also create user-specific feeds that contain post IDs that each user is eligible for. Then each user just subscribes to changes in their feed and fetches the new posts. Something like that.

I hope this helps