Why can a "hot" record or table become a bottleneck under heavy Mnesia write load?

Because Mnesia uses per-record (or sometimes per-table) locking inside transactions, any record that many concurrent transactions all need to write to becomes a serialization point: every transaction touching it has to wait its turn for the write lock, no matter how many CPU cores or schedulers are otherwise free. A single shared counter or a global "last updated" timestamp record are classic examples of accidental hot spots.

%% classic hot-spot pattern: every request updates the same record
mnesia:transaction(fun() ->
    [C] = mnesia:read({counter, global_hits}),
    mnesia:write(C#counter{value = C#counter.value + 1})
end).

As concurrency increases, throughput on that specific record plateaus (and transactions start piling up waiting on its lock) well before the rest of the system's capacity is exhausted, since the bottleneck isn't CPU or I/O — it's contention for one specific lock. This shows up as rising transaction latency and retries concentrated on operations touching that one hot record, even while the node's overall load looks otherwise unremarkable.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.