here is an example:

bootstrapping boilerplate grouped at the top,

API section with comment fence in the middle, each function grouped with its implementation
Some indirect API functions that are not "do_"s because they are called externally when the system sends a message.

(no do_'s in this particular module), that’s because I forgot to label “start_server” as “do_start_server”.

router on the bottom. Ideally, you should rarely if ever have to examine the router code once written.

Also, if I have a server (genserver or state machine) that has very complex state requirements (aka, not a single scalar or simple list) I prefer to have the internal kept datastructure a struct, and usually I declare typing info on it too.

Last rule is, if you don’t really need state, don’t use it. I only use genservers and gen_statems/state_server when I absolutely have to model the state of something IRL, or some sort of stateful communication protocol. For everything else there’s Tasks, (or it’s linear, functional, stateless code running in “someone else’s” process, like a liveview for example).