<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Scalability on Martin C. Richards</title>
    <link>//www.martinrichards.me/tags/scalability/</link>
    <description>Recent content in Scalability on Martin C. Richards</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sun, 18 Jan 2026 12:00:00 +0200</lastBuildDate>
    <atom:link href="//www.martinrichards.me/tags/scalability/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Real-Time Ledger Systems: Scaling a Double-Entry Ledger for a Massive PSP</title>
      <link>//www.martinrichards.me/post/ledger_p2_scaling_double_entry_ledger_massive_psp/</link>
      <pubDate>Sun, 18 Jan 2026 12:00:00 +0200</pubDate>
      <guid>//www.martinrichards.me/post/ledger_p2_scaling_double_entry_ledger_massive_psp/</guid>
      <description>&lt;h1 id=&#34;scaling-a-double-entry-ledger-for-a-massive-psp&#34;&gt;Scaling a Double-Entry Ledger for a Massive PSP&lt;/h1&gt;&#xA;&lt;p&gt;In &lt;a href=&#34;//www.martinrichards.me/post/ledger_p1_optimistic_locking_real_time_ledger/&#34;&gt;Part 1&lt;/a&gt;, we built a real-time double-entry ledger using optimistic locking. We benchmarked it and found it handles &lt;em&gt;160-440 req/sec&lt;/em&gt; depending on contention, with zero errors and stable tail latencies. But benchmarks on localhost are one thing. &lt;strong&gt;Production at PSP scale is another.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This post answers the question: &lt;em&gt;Can this architecture handle a massive Payment Service Provider processing 10 million transactions per day?&lt;/em&gt; Spoiler: &lt;strong&gt;Yes, but only if you get the account hierarchy right.&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
