I really wished to see an OTP-first design. Unfortunately for me, the code is almost procedural as it's touching ETS or Application, which is built on ETS, in nearly every operation.

If the author wishes to learn how to design services in Elixir, or any BEAM language, with OTP, they can take a look at "Designing Elixir Systems with OTP" by by James Edward Gray and Bruce Tate, and "Functional Web Development with Elixir, OTP, and Phoenix" by Lance Halvorsen.

On my first try I did write it in a more OTP-y style but the scaling potential for this very specific flow is just not the same. In the end a torrent tracker is just a specialized database and handling the data as fast as possible is the top objective. That said I'll give the books a go.

If, like me, you don't know what OTP means in this context, here it is:

OTP stands for Open Telecom Platform, although it's not that much about telecom anymore (it's more about software that has the property of telecom applications, but yeah.) If half of Erlang's greatness comes from its concurrency and distribution and the other half comes from its error handling capabilities, then the OTP framework is the third half of it.

https://learnyousomeerlang.com/what-is-otp

Building a BitTorrent tracker out of GenServers makes zero sense. ETS is the correct choice to make here 100% (for a single server configuration). Obviously it doesn't scale horizontally but it will scale vertically to the moon and chances are, yagni anyway

A lot of the glory of Elixir and Erlang are in that you can write code that is very straightforward but performs well.

There may be cool cases for extra GenServers or gen_statems but a lot of uses of Elixir and Phoenix don't warrant making any fancy architectural choices. Partly because the runtime is already fancy for you.

Out of curiosity, what would an "OTP-first" design look like?

ETS is built into OTP, so how is using ETS not "OTP-first"? What's wrong with using ETS? It's just an in-memory store.

I looked through the code and didn't find it to be anywhere close to procedural in style.