A cool pattern in Erlang/Elixir might eliminate 80% boilerplate code in async/trivial distributed programming

Chat / Discussions
1

TLDR: What is SupersedeServer?
GenServer with mailbox ordered by logical clock.

In Elixir, we often have to code things like %{version: 100} or %{step: 10} to manually check if an async message arrives in the right order. I found a general pattern to make this effortless.

Here is a cool pattern in Erlang/Elixir might eliminate 80% of ordering boilerplate code: a GenServer wrapper called SupersedeServer. Its goal is simple: ensure Actor-Local Correctness by ordering messages via Hybrid Logical Clocks (HLC) or Lamport Clock.

Core Concept:

Instead of standard handle_cast/call, the user implements two callbacks:

  1. handle_clocked: Invoked for messages that appear in non-descending order (HLC + PID tie-break).

  2. handle_supersede: Invoked when a message is “late” (logically older than the current processed state).

How it works:

  • Mailbox Draining: It utilizes a recursive receive loop to batch and sort incoming messages locally before processing.

  • Simple Semantics: “Late means superseded.” There are no watermarks or vector clocks. If it arrives late, it’s handled separately (usually discarded or logged) without rolling back state.

  • Safety: It includes a “Max Offset” check to reject clocks drifting too far into the future and a safety valve to crash if too many superseded messages accumulate (protecting CPU).

This pattern explicitly abandons global causal consistency to focus strictly on ensuring a single actor’s state never logically regresses. Another cool thing is that in BEAM the integer will never overflow which makes it perfect for integer-based logical clocks.

I’d love to hear your thoughts on this approach!

4 Likes
2

Can you give a concrete example of when you need to do this? Messages from the same sender process will always appear in order. Messages from different sender processes don’t have a order per se, unless they were triggered by a common source process but took different routes through intermediate processes. However, I’d argue that it might be more intuitive to reduce the number of process hops.

4 Likes
3

There are situations where you might want to do such a thing, but they are generally very complicated and domain-specific. I am skeptical that a general solution is a good idea here. Message passing is a very good primitive, as you suggest.

Also, in general I think causal consistency is weak and bad and it’s virtually always better to use a timestamping server (here a process) to give out linearizable versions. Or you can use extremely accurate clocks if you have them laying around, but unless your market cap is >$1T you’re probably not on that list. Though AWS will sell them to you, I guess, if you trust them.

4

There are situations

exactly, basically anywhere you might need consistency but you don’t want to code consistency everywhere(no fun to debug partial orders which human brain can’t really handle well except for some top theory physicists).