One common pattern to implement TTL is the following: the process that maintains the state (usually a GenServer) upon setting some data in the state would also send a delayed message to itself with Process.send_after/4 with a timeout equal to the TTL. The delayed message would contain some reference to the data to expire (for example the key, if it is some sort of key/value cache). Upon receiving the message, the GenServer would clear the expired data.

Another common pattern is to invalidate the cache lazily: the cached data would contain a timestamp, and upon retrieval the process would check if the cached value is stale, and if so evict it and consider it a cache miss. This would mean that a value could stay in cache forever if it’s never requested, so often one would implement some sort of fixed-capacity cache (like an LRU cache), or periodically clean up the expired values by enumerating or sampling the entries.

Along with the the start_link alternative Luca presented, if you need more than one running copy of a process within a single BEAM node that you can still reference from elsewhere “by name”, take a look at stdlib’s Registry and via-tuples.

From there, another refinement of Luca’s later suggestions would be to brush up on child specifications and child_spec/1 which give you finer control over the relationship between “how I supervise this process” and “how it receives arguments”. You’re not limited to a single catch-all argument if you don’t want to be or if it doesn’t make sense for your purposes. This technique translates to many OTP process types and isn’t limited to just GenServers, either.

Everything you described should be doable with Cachex. It also has a TTL implementation. You don’t have to reinvent it unless it’s a learning project.

That’s really helpful, thank you!

If the GenServer is started “statically” as part of the supervision tree, it is often convenient to give it a name. In my example above, we could change Cache.start_link to set a name for the GenServer:

def start_link(options \\ []) do
  {name, options} = Keyword.pop(options, :name, __MODULE__)
  GenServer.start_link(__MODULE__, options, name: name)
end

Here I am forwarding the options as the second argument of GenServer.start_link/3 after extracting the name, so they will be passed to init: that’s not relevant for our case, but it is a common way to pass other options to the GenServer process.

Defining start_link to take a single argument is useful, because in the Supervisor we can specify children as tuples of {module, arg}, and the Supervisor will start them by calling module.start_link(arg). So we can add this to the list of children:

children = [
  # Here we specify children as tuple of {module, argument_of_start_link}
  {Cache, []}
]

And we could then refer to it by name (which in start_link we set by default to the module name, if not explicitly passed):

Cache.get(Cache, :foo)

Or, if we prefer to assign a different name to it (for example if we want to start more than one processes from the same module):

# Supervisor:
children = [
  # ...
  {Cache, name: :my_cache}
]

# usage:
Cache.get(:my_cache, :foo)