It’s a bit hard to recommend the concrete approach, because the description is quite vague, but I’ll give it a try

To avoid ambiguity with the term channel, I’ll use the term topic instead.

My first take on this would be to use a separate GenServer for each topic. You could hold all the transient data of the topic in that server. The server would also need to keep track of whether it’s in the quite mode. So now, whenever someone wants to send a message to the topic, they need to do it through the corresponding server. Since the server knows about its mode, it can easily decide whether to send the message or not.

Adding expiry logic can now be fairly simple with the help of :timer.send_interval or Process.send_after which would be invoked in the topic server. Either approach will result in some message sent to the server, which you’d need to handle in the corresponding handle_info and remove expired items.

This approach is very consistent, and when done properly, you’ll have no race conditions or strange behaviour. However, the topic server might turn out to be a bottleneck if you have frequent activity on a topic (frequent messages, mode changes, or other state changes). In that case, you could consider using an ETS table. ETS tables can boost your performance significantly, but they are appropriate only for some situations, so you need to think it through. In some cases a hybrid approach is needed, where all the writes are serialized through the server process, while reads are performed directly from the table.

If you go for ETS tables, and want to expire items, you could look into some of the caching libraries, such as CachEx, or my own con_cache. Cachex has more features and higher activity, so as the author of con_cache, I’d myself recommend looking into Cachex first.

If the transient state is really simple, then I’d consider ETS from the start. For example, if we only need to deal with the quiet mode, then I’d just have one ETS table where I’d store that info for each topic.

In more complex cases, I’d start with GenServer and do some testing to see if it can handle the desired load.

Again, the problem is vaguely defined, so it’s hard to precisely say which of the two would be a more suitable choice in this particular case.

Yes I understand I didn’t specify the domain very accurately here, thanks for giving your input nevertheless! It’s actually very interesting building a sort of modern administrated Multi-User Chat on Elixir/Phoenix, without the headaches of XMPP.

The nature of my application is:

• topics are set up (=transient state established) whenever a user subscribes to it as the first user
• a topic dies when the last user leaves it (=transient state is wiped clean)
• lots of topics are born and die constantly at a high frequency
• some topics will be massive = having tons of users subscribed to them, actively sending messages

The transient state each topic has:

• title - changes rarely
• member privileges (VIP etc.) - currently this is stored in socket.assigns, which feels like the best approach
• keyword list - a list of strings which changes constantly based on user messages. These will each have an expiry time, and I believe the birth & expiry logic will get very complex as the app evolves
• quiet mode (boolean) - will change rarely but needs to be checked on just about every message sent
• message history - a list of the past (max) 100 messages or so. I want to avoid saving this persistently for now.

So my trouble has been trying to decide whether to make one sort of global state tree (like :mnesia) or whether to prefer more local approaches for each topic.

Your GenServer approach was also my first thought, but I read somewhere that in big topics (lots of subscribers) the GenServer could become the bottleneck, as it is just one process. Now I’m thinking to use a GenServer for the keyword list and maybe for the message history, and ETS / CachEx or your con_cache for the rest.

By the way, is there any reason not to prefer :mnesia over ETS? From what I understand, if I use the transactions :mnesia could be a more safe choice, although it does carry some performance penalty. However, that way, I wouldn’t need to serialize the writes through a channel specific GenServer, but I could still perform fast dirty_reads (if that makes sense).

Honestly the way you’re doing it sounds totally reasonable. Queries to ram or disc copy mnesia tables go through ETS which is fast. In fact I think pg2 phoenix pubsub hits ETS a couple times on every broadcast anyway.

I have a process like you suggest to expire keys, although it’s for postgresql rather than mnesia, and it works great. It doesn’t get much load anyway so I never bothered optimizing or sharding its work.