<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[GritCore Lab]]></title>
  <link>https://gritcorelab.com/</link>
  <description><![CDATA[GritCore Lab: a distributed financial transactions database with strict serializability, synchronous multi-region replication, and 0.4 ms commit latency. Based in Okayama, Japan.]]></description>
  <language>en</language>
  <atom:link href="https://gritcorelab.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[Horizontal Read Scaling Without Sacrificing Write Consistency]]></title>
    <link>https://gritcorelab.com/notes/horizontal-read-scaling-transaction-database.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/horizontal-read-scaling-transaction-database.html</guid>
    <description><![CDATA[A common concern about strict serializability is that it limits throughput. On the write path, this is partly true: the two-phase commit protocol and synchronous replication add latency that a weaker consistency model would not incur. On the read path, however, strict serializability does not require reads to go through the leader, and GritCore Lab takes advantage of this to scale read throughput horizontally.]]></description>
    <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Why Strict Serializability Matters for Financial Databases]]></title>
    <link>https://gritcorelab.com/notes/strict-serializability-financial-databases.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/strict-serializability-financial-databases.html</guid>
    <description><![CDATA[Most relational databases offer serializable isolation as their strongest consistency guarantee. Strict serializability is stronger, and the difference is not academic. For a financial settlement ledger, the gap between the two can be the difference between a system that requires a reconciliation job and one that does not.]]></description>
    <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[WAL Archival and FSA Compliance for Transaction Databases in Japan]]></title>
    <link>https://gritcorelab.com/notes/wal-archival-fsa-compliance-japan.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/wal-archival-fsa-compliance-japan.html</guid>
    <description><![CDATA[Japan's Financial Services Agency requires financial institutions to maintain accurate and complete records of transactions for specified retention periods. For a database-backed system, the most reliable way to satisfy this requirement is to archive the write-ahead log in a verifiable format, rather than relying on periodic backups or application-level export jobs.]]></description>
    <pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Synchronous vs Asynchronous Replication in Financial Systems]]></title>
    <link>https://gritcorelab.com/notes/synchronous-replication-vs-async-financial-systems.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/synchronous-replication-vs-async-financial-systems.html</guid>
    <description><![CDATA[Replication is how a database survives the failure of a single node. The question of whether that replication is synchronous or asynchronous is one of the most consequential architectural decisions in a financial system, and it is frequently made without a full understanding of what asynchronous replication actually risks.]]></description>
    <pubDate>Wed, 20 May 2026 00:00:00 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Bounded Crash Recovery: What It Means and How to Measure It]]></title>
    <link>https://gritcorelab.com/notes/crash-recovery-bounded-time-database.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/crash-recovery-bounded-time-database.html</guid>
    <description><![CDATA[Crash recovery time is one of the least-discussed performance characteristics of a database, and one of the most consequential for financial systems. A database that takes ten minutes to recover after a node failure is unavailable for ten minutes. For a settlement system processing time-sensitive transactions, that is not acceptable.]]></description>
    <pubDate>Thu, 02 Apr 2026 00:00:00 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[CAP Theorem and Financial Database Design: Choosing Consistency]]></title>
    <link>https://gritcorelab.com/notes/cap-theorem-financial-database-design.html</link>
    <guid isPermaLink="true">https://gritcorelab.com/notes/cap-theorem-financial-database-design.html</guid>
    <description><![CDATA[The CAP theorem states that a distributed system cannot simultaneously guarantee consistency, availability, and partition tolerance. In practice, network partitions happen, so the real choice is between consistency and availability. For a financial transaction database, this is not a difficult choice, but it is worth understanding what each option actually means operationally.]]></description>
    <pubDate>Tue, 10 Mar 2026 00:00:00 GMT</pubDate>
  </item>
</channel>
</rss>
