+1 to @cmo’s question about ownership - some of the places that could ultimately end up calling :ets.new are Cowboy workers and Liveviews, which will lead to the table disappearing before you want it to.

Giving the table a more-reliable parent can also reduce the need for all the “does the table exist” guards, since the table should be created during system boot.

Some other thoughts:

• :ets.info/2 will return :undefined if the table doesn’t exist yet. Clearer + faster than searching the output of :ets.all

• this call to :ets.lookup will not succeed… ever, because the second argument to lookup should be the key (edge_init.id) and not the whole tuple.

  edge_kv = {edge_init.id, edge_init}
  
  case :ets.lookup(:edges, edge_kv) do
    [] ->
      :ets.insert_new(:edges, edge_kv)
  
    _ ->
      :ets.insert(:edges, edge_kv)
  end
  

• also in that code chunk: the case between insert and insert_new is odd. The only difference between the two functions is their behavior if there’s an existing element with the same key, and the lookup prevents that from being relevant. What’s the intent of this structure?

• get_raw_by_id is inefficient; look into :ets.select to avoid copying the entire table into your process. Alternatively, if lookups by edge_id are very frequent, you could maintain a separate bag table of {edge_id, edge} pairs.

• delete_raw_by_id tries to pass a list of tuples to :ets.delete - like lookup, that function expects a single key.

Is there a process that owns the ETS table?

Why not use Cachex? It’s battle tested, works flawlessly, and has a ton of features.