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:
group data - key is <group_uuid>
group member list - key is <group_uuid>_members
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.
Last updated