Design the group-membership service for a chat platform: the authoritative source of truth for who belongs to each group or channel, what role they hold (owner, admin, member), and therefore who is allowed to read and post. Every message fan-out and every permission check consults it, so it is one of the hottest read paths in the product.

Operating context. Groups range from three people to public channels with hundreds of thousands of members, and the read rate dwarfs the write rate: membership is looked up on essentially every message sent, while joins, leaves, removals, and role changes are comparatively rare. Correctness on the write path matters intensely, since when an admin removes a member that member must stop receiving new messages promptly and a revoked poster must be unable to post, so bounded staleness on removals is a first-class requirement even though reads are heavily cached. Membership changes must be ordered and auditable. Roles gate actions: only admins can add members, only owners can delete the group.

Out of scope. The message-delivery and fan-out mechanism itself, the socket layer, presence, and content moderation. Assume the fan-out service calls you to resolve a group's current members and that individual permission decisions are enforced by callers using the role data you return.

What to produce. A high-level architecture covering: the membership and role data model and its partitioning, the hot read path that resolves a group's members for fan-out and permission checks, how membership changes are applied consistently and ordered, how removals propagate with bounded staleness despite aggressive caching, how very large groups are represented without a huge read per message, and the audit trail. Sketch the components and both request paths; checkpoints will probe removal consistency and large-group reads.