It sound like you could take advantage of both approaches.

If all you need to achieve the task is procedural code maybe you don’t need a GenServer:

def compare(event_1, event_2), do: send_email("email")

But you would need to have received both events to execute this function. If events come and go at different times you could use laziness to defer computation:

def lazy_compare(event), do: 
  (fn later_event -> compare(event, later_event) end)

And just wait until your next input is ready so you can execute the returned function at a later time.

If you really don’t need the GenServer, yes it is a wasteful (but cheap) approach. A GenServer would be a solution to handle asynchronous calls; just be careful because you may already have this in the form of a Phoenix Server, HTTP Request or iex session, but if you’re creating your custom “subscription / publish” mechanism a GenServer would be a great way to go.

If you haven’t, I suggest you read the to spawn or not to spawn article by @sasajuric; it may help to re-arrange some thoughts on when and where to use processes.

btw, if you end up going the Postgres notifications route, I found this article (and the other article the author links to) useful in getting an initial handle on how notifications work: https://medium.com/@kaisersly/postgrex-notifications-759574f5796e

Sounds a lot like CQRS, and to be honest that kind of pattern really falls outside my area of expertise .

But if you would like a separate entity to take care of the handling would Task.Supervisor or DynamicSupervisor work for you? That way you would could spawn a process “on request”.