System designMedium~16 minCore Designs / 20 of 30

Interview question

Design backend APIs for changing team membership and roles inside a SaaS account.

Design team membership and role changes

Designs membership, role changes, removal, ownership transfer, and permission updates without weakening tenant boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would model users separately from memberships. A membership belongs to an account or tenant and contains role, status, timestamps, and who created or changed it. APIs for add, remove, activate, deactivate, and change role would check the actor's capabilities inside the same tenant. Removing a member disables future access to tenant resources while preserving historical ownership and audit records.

Full answer below

Practice focus

Membership modeling, capability checks, ownership transfer, role updates, removal behavior, audit logging, and consistency.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Membership APIs look like ordinary CRUD, but they control who can access customer data. The design needs a clear permission boundary and safe handling for the last owner, removed users, and role changes.
I would model users separately from memberships. A membership belongs to an account or tenant and contains role, status, timestamps, and who created or changed it. APIs for add, remove, activate, deactivate, and change role would check the actor's capabilities inside the same tenant. Removing a member disables future access to tenant resources while preserving historical ownership and audit records.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define business invariants explicitly. A tenant might require at least one owner, block users from removing themselves as the last admin, and prevent assigning roles above the actor's authority. Role changes need audit records and may require invalidating cached permissions or active sessions. The API response can include the effective capabilities so the UI and backend agree on what changed.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make membership changes observable and recoverable. Privileged role changes may require confirmation, step-up authentication, or a second approval depending on risk. Permission cache invalidation matters because stale access after removal is a security bug. I would track denied membership changes, role elevation events, last-owner protection, and support recovery paths for accidental lockout.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating global user role as the same thing as tenant membership.
Allowing removal of the last owner without a recovery path.
Forgetting to invalidate permission caches or active sessions.
No audit event for privileged role changes.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain tenant-scoped authorization.
Allows users to grant permissions above their own authority.
Ignores historical records after member removal.
Has no plan for accidental admin lockout.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you prevent the last admin from being removed?
How would active sessions react to role changes?
What information belongs on the audit event?

Continue the section

Next in Core Designs: Bulk Import Preview

Step 21 of 30

Design bulk import preview and validation

Opening drill

System designMedium~16 minCore Designs / 20 of 30

Interview question

Design backend APIs for changing team membership and roles inside a SaaS account.

Design team membership and role changes

Designs membership, role changes, removal, ownership transfer, and permission updates without weakening tenant boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Membership modeling, capability checks, ownership transfer, role updates, removal behavior, audit logging, and consistency.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Membership APIs look like ordinary CRUD, but they control who can access customer data. The design needs a clear permission boundary and safe handling for the last owner, removed users, and role changes.
I would model users separately from memberships. A membership belongs to an account or tenant and contains role, status, timestamps, and who created or changed it. APIs for add, remove, activate, deactivate, and change role would check the actor's capabilities inside the same tenant. Removing a member disables future access to tenant resources while preserving historical ownership and audit records.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define business invariants explicitly. A tenant might require at least one owner, block users from removing themselves as the last admin, and prevent assigning roles above the actor's authority. Role changes need audit records and may require invalidating cached permissions or active sessions. The API response can include the effective capabilities so the UI and backend agree on what changed.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make membership changes observable and recoverable. Privileged role changes may require confirmation, step-up authentication, or a second approval depending on risk. Permission cache invalidation matters because stale access after removal is a security bug. I would track denied membership changes, role elevation events, last-owner protection, and support recovery paths for accidental lockout.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating global user role as the same thing as tenant membership.
Allowing removal of the last owner without a recovery path.
Forgetting to invalidate permission caches or active sessions.
No audit event for privileged role changes.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain tenant-scoped authorization.
Allows users to grant permissions above their own authority.
Ignores historical records after member removal.
Has no plan for accidental admin lockout.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you prevent the last admin from being removed?
How would active sessions react to role changes?
What information belongs on the audit event?

Continue the section

Next in Core Designs: Bulk Import Preview

Step 21 of 30

Design bulk import preview and validation

Design backend APIs for changing team membership and roles inside a SaaS account.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Design backend APIs for changing team membership and roles inside a SaaS account.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section