Redis

Caching of API responses in groups service is implemented using Redis (DB index: 0).

Group create, update and delete APIs deletes the cached data from Redis and Group read and list APIs populates the cache with the updated data from database.

3 types of group data are stored in Redis:

1. group data - key is <group_uuid>

2. group member list - key is <group_uuid>_members

3. group list for a user - key is <user_uuid>

There is a separation proposed to independently scale members and activities. We could expect activities to be having content metadata (size=big) and other metadata (size=small). The member data is relatively a list of alike fields and therefore will directly be related to the count of members.

Identifier	Data refresh when?	TTL	Comments
groupId_members	Members added/role changes/removed	1d	Members of this specific group. Likely less or no changing once group is formed. Members might get added only infrequently. But when a member gets added/updated/removed from group this cache gets deleted. The member name changes within 1d is less likely to reflect. This TTL can be tweaked as its an env var.
userId	When the user reads his groups	1h	Groups the user belongs. This is populated only after a read of this user by calling /group/v1/list. When a member gets added/updated/removed from group this cache gets deleted, along with groupId_members. The activity info changes within 1h is less likely to reflect. This TTL can be tweaked as its an env var.
groupId	Group name, description changes Add/Remove activities	1d	Group name, description and activities. Likely less changing, but often in the initial days. Activity data within a group - like leaf nodes etc - would it get updated within the TTL? - this was discussed with DC and found to be okay to live with. When group information gets updated or activity is added/removed, this cache gets deleted.