ریاضیات دقیق پول و دفتر کل مالی
معماری state مالی با محاسبات صرفاً عدد صحیح، دفتر کل فقط-افزودنی، ردپای ممیزی و مرزهای تراکنشی ACID
ریاضیات مالی صرفاً عدد صحیح (Integer-Only)
پول به عنوان کوچک‌ترین واحد، نه عدد اعشاری ممیز شناور
سیستم مالی نباید پول را مثل عددهای معمولی UI رفتار دهد. مقدارهای ممیز شناور بر اساس نمایش باینری IEEE-754 کار می‌کنند؛ برای بسیاری از محاسبات علمی و نمایشی مناسب‌اند، اما برای موجودی، تسویه، تخفیف، کارمزد و جمع دفتر کل خطرناک می‌شوند. همین driftهای ریز وقتی در هزاران تراکنش تکرار شوند، به مسئله واقعی یکپارچگی داده تبدیل می‌شوند.
قرارداد امن‌تر، پول صرفاً عدد صحیح است: هر مبلغ در کوچک‌ترین واحد پولی، مثل ریال یا سنت، با integer یا bigint ذخیره و محاسبه می‌شود. فرمت اعشاری فقط در مرز نمایش UI ساخته می‌شود. این مدل محاسبات را deterministic نگه می‌دارد، aggregateهای دیتابیس را قابل اعتماد می‌کند و اجازه نمی‌دهد خطای گرد کردن پنهان وارد هسته مالی شود.
پترن دفتر کل فقط-افزودنی (Append-Only Ledger)
موجودی مشتق‌شده از رکوردهای غیرقابل تغییر، نه ستون قابل ویرایش
فیلد موجودی می‌تواند یک projection مفید باشد، اما نباید منبع حقیقت مالی باشد. وقتی موجودی حساب با SQL UPDATE مستقیم تغییر می‌کند، state نهایی عوض می‌شود اما دلیل، منبع و ردپای ممیزی آن تغییر ممکن است از بین برود. در سیستم مالی، تاریخچه خودش بخشی از دارایی است.
در الگوی دفتر کل فقط-افزودنی، هر جابه‌جایی پول به عنوان entry غیرقابل تغییر ثبت می‌شود. انتقال‌ها به جفت رکورد بدهکار و بستانکار تبدیل می‌شوند و موجودی فعلی از SUM رکوردهای معتبر به دست می‌آید. نتیجه این است که موجودی در هر لحظه قابل بازسازی، قابل بررسی، قابل تطبیق و قابل ممیزی است؛ بدون overwrite خاموش و بدون state بی‌توضیح.
مدیریت همزمانی و تراکنش‌های اتمیک ACID
قفل سطر، مرز isolation و جلوگیری از خرج‌کردن مضاعف
همزمانی بالا مسئله موجودی را فقط به مسئله performance تبدیل نمی‌کند؛ مسئله correctness می‌سازد. اگر دو درخواست قبل از commit شدن یکدیگر، همان موجودی آزاد را بخوانند، هر دو ممکن است برداشت را معتبر بدانند. بدون مرز تراکنشی، state مالی می‌تواند به overdraft، برداشت تکراری یا ledger ناسازگار برسد.
مدل درست این است که اعتبارسنجی و تغییر state مالی داخل یک تراکنش ACID انجام شود. قفل‌هایی مثل SELECT ... FOR UPDATE، سطح isolation مناسب و بررسی دوباره موجودی پیش از commit باعث می‌شوند درخواست‌های همزمان حول یک منبع حقیقت صف شوند. یک تراکنش commit می‌شود و دیگری منتظر می‌ماند، دوباره بررسی می‌شود یا پیش از ثبت ledger نامعتبر رد می‌شود.
ممیزی‌پذیری و صحت تعادل محاسبات
reconciliation دوره‌ای، تراز صفر و تاریخچه قابل اثبات
درستی مالی با commit شدن تراکنش تمام نمی‌شود. دفتر کل پروداکشن به یک تراز اثبات دوم نیاز دارد: هر projection باید از entryهای غیرقابل تغییر قابل بازسازی باشد، هر انتقال باید جمع بدهکار و بستانکار را در تعادل نگه دارد و هر اختلاف مشکوک باید قبل از اعتماد به موجودی گزارش‌شده، به هشدار عملیاتی تبدیل شود.
مدل ممیزی، موجودی‌ها را به صورت دوره‌ای از ردیف‌های ledger بازسازی می‌کند، برابر بودن جمع بدهکار و بستانکار را می‌سنجد، پیوستگی hash تراکنش‌ها را بررسی می‌کند و اگر اختلاف ببیند، projection مشتق‌شده را مسدود می‌کند. نتیجه این است که state مالی فقط یک عدد نیست؛ سندی قابل بازپخش، قابل تحقیق و قابل اثبات است.
معماری کامل شد؛ حالا نوبت مهندسی سیستم شماست.
از مدل محصول تا زیرساخت اجرا و از دیتابیس تا دفترکل مالی، تمام ۶ فاز به یک اصل ختم می‌شود: سیستم‌های حساس باید قابل ردیابی، تاب‌آور و قابل ممیزی باشند. برای معماری یا ممیزی فنی پلتفرم خود، گفتگو را آغاز کنید.