Is manual cleanup of unused interest groups required in Photon Realtime, or can custom properties replace them?

Short answer

You do not need to clean up interest groups at room boundaries — subscriptions are discarded automatically when the client leaves the room, and they are not persisted across reconnects. You do need explicit cleanup while the client stays inside a long-lived room and stops caring about a group, both to stop receiving unwanted traffic and to stay under the per-client group cap. Custom properties are a different mechanism (shared state, not a routing channel), so they cannot fully replace interest groups for targeted, high-frequency event filtering.

What is confirmed vs. what is a recommendation

Confirmed behavior (well-established Photon Realtime semantics):

• Interest groups are a per-client subscription filter. A client only receives events published to groups it subscribed to via OpChangeGroups; publishing targets a group number.
• Subscriptions live only for the client's presence in the room. Leaving the room (or disconnecting) resets them — a rejoining client starts with no group subscriptions.
• There is a per-client cap on group subscriptions (commonly cited as 255). Exceeding it makes the change-groups operation fail; the server does not evict old groups for you.
• There is no server-side garbage collection of "unused" groups. Groups are just byte identifiers — they cost nothing on the server when nobody is subscribed.

Recommendation (the part docs don't prescribe): treat subscription lifecycle as mirror of your logical contexts. Subscribe when entering a context (a zone, a team, a match phase), unsubscribe via OpChangeGroups(null, groupsToRemove) when leaving it, and treat room leave as a full reset — no cleanup call needed there.

Is letting groups linger until the cap acceptable?

Only if your room sessions are short or your group count is small and bounded. The cost of lingering is not server-side — it is bandwidth: the client keeps receiving every event published to groups it no longer cares about, and on Photon Cloud, message volume is what you pay for. In a long-lived room with dynamic contexts (e.g., a player moving between map zones), failing to unsubscribe means steadily rising receive traffic and eventually a failed OpChangeGroups call at the cap. So: cleanup is cheap, do it on context change, not on room exit.

Do custom properties eliminate the need for interest groups?

No — they solve a different problem. Room and actor custom properties are key-value state that the server broadcasts on change. They are not a publish/subscribe routing channel. You can emulate filtering with them only indirectly: publish all events to everyone, attach a property (e.g., team ID), and have clients locally discard irrelevant events. That works when filtering is coarse and event volume is low, but every client pays the receive cost for every event, which inflates message counts and client processing.

The pattern that tends to work well in practice is a hybrid:

• Interest groups for high-volume, audience-segmented traffic — per-zone position updates, per-team chat, per-match-phase events.
• Custom properties for slowly changing shared state — current match phase, team rosters, map seed — where a broadcast-on-change model is exactly what you want.

Verifying this in your setup

Exact API surface and limits vary between client SDK versions and Cloud vs. self-hosted Server configurations, so verify rather than trust the numbers:

1. Subscribe a client to group 5, leave and rejoin the room, publish to group 5, and confirm the rejoined client receives nothing. This confirms the reset-on-leave behavior in your SDK.
2. Subscribe to groups in a loop until OpChangeGroups returns an error to confirm the effective cap under your plan.
3. Log per-second received event counts with and without unsubscribing from an active group to quantify the bandwidth cost of lingering subscriptions.
4. If you're considering the custom-properties route for one event type, prototype it and compare per-client message rates against the group-based version before committing.

One caveat worth flagging: the 255 figure and the exact OpChangeGroups overloads should be checked against the SDK version you ship with — treat them as configuration-dependent, not universal constants.