Англійська для розробників TigerBeetle
Словник для розробників, що працюють з TigerBeetle — бухгалтерський облік з подвійним записом, бухгалтерські книги, дебети і кредити, пов’ язані події і детерміністичне тестування моделювання — для команд, які обговорюють бази даних фінансових операцій англійською мовою.
TigerBeetle — це розподілена база даних, призначена для фінансових операцій, розроблена навколо подвійного запису бухгалтерського обліку, а не рядків і стовпців загального призначення. Його словник походить з двох світів одночасно - бухгалтерських термінів, таких як “дебет” і “книга”, і розподілених системних термінів, таких як “детерміністичне моделювання” - тому команди, що оцінюють його, повинні вільно говорити про це точно. Ось англійська для обговорення дизайну і перегляду коду.
Основні принципи бухгалтерського обліку
** Бухгалтерський облік з подвійним записом ** — модель бухгалтерського обліку, за якої кожна операція записується з двома відповідними записами — дебет на одному рахунку і кредит на іншому — отже, книги завжди балансуються за конструкцією.
- “Ми створили модель перенесення торбинки як обліку з подвійним записом замість оновлення балансу один раз, отже, баґ ніколи не зможе беззвучно створити або знищити гроші.” *
** Дебет і кредит ** — дві сторони кожного переказу; дебет зменшує вільний баланс одного рахунку, а відповідний кредит збільшує інший, і TigerBeetle намагається, щоб їх сума завжди була рівна нулю.
- “Переказ не пройшов перевірку, оскільки дебетовий і кредитний рахунки були в двох різних валютах — TigerBeetle не дозволить провести невідповідність балансу.” *
** Ledger ** — логічне групування рахунків і переказів, які мають спільну валюту або бізнес- домен, використовується для зберігання непов’ язаних балансів, ізольованих один від одного. “Ми розділили очки нагороди і баланси готівки на окремі книги, оскільки змішування їх арифметики в одній книзі ускладнило прирівнювання.”
Розрахунки і перекази
Account
** рахунок ** в TigerBeetle є записом балансу - як гаманець користувача або платіжний баланс продавця - ідентифікований 128-бітним ідентифікатором для глобальної унікальності в розподільному кластері.
- “Кожен користувач отримує один обліковий запис на валюту, створений заздалегідь, отже, переказ ніколи не повинен непрямо створювати відсутній обліковий запис у середині транзакції.” *
Transfer
** Перенесення ** — це атомарна операція, яка переносить значення між двома рахунками, записуючи дебет на одному і кредит на іншому у єдиному, незмінному записі.
“Якщо переказ опубліковано, ми не редагуємо його — якщо потрібний повернення коштів, ми створюємо новий переказ у протилежному напрямку замість зміни історії.”
Зв’язані події
** Поєднані події ** надає вам змогу з’ єднати декілька перенесень у ланцюжок, щоб всі вони завершилися успішно або всі зазнали невдачі, надаючи вам можливість атомізувати дії, які інакше були б окремими викликами.
- “Ми використовували пов’ язані події для з’ єднання відрахування плати і виплати продавцю — якщо виплата не відбудеться, відрахування плати буде відновлено разом з нею.” *
Двухфазний трансфер
** Двофазний переказ ** спочатку резервує кошти (затримка) і завершує їх пізніше (пост або скасування), це корисно для таких затримок, як готельний депозит або попередня авторизація.
“Ми моделювали передавторизацію картки як двофазний переказ - кошти утримуються як очікувані доки торговець або не опублікує або не скасує списання.”
Надійність і тестування
** Детерміністичний тест моделювання ** — запуск всієї розподіленої системи всередині моделі мережі з введеними помилками (випадаючими пакетами, відхиленням годинника, аваріями), щоб вади можна було відтворити з одного джерела, замість того, щоб їх було багато і вони залежали від середовища.
“Модель знайшла рідкісну помилку відновлення репліки менше ніж за годину моделювання - це б зайняло місяці, щоб з’явитися в виробничому трафіку.”
** Протокол консенсусу (реплікація з відбитками огляду) ** — алгоритм, який використовують репліки TigerBeetle для узгодження порядку перенесення, навіть якщо деякі вузли або розділи мережі зазнають аварії.
“Ми не потребуємо зовнішнього координатора для відключення — протокол консенсусу обробляє вибір лідерів і репродукцію угоди внутрішньо.”
Пояснення TigerBeetle команді
| Situation | Phrase |
|---|---|
| Justifying it over a general-purpose DB | ”Once we needed atomic, auditable money movement at high throughput, a purpose-built accounting database beat rolling our own balance logic on Postgres.” |
| Explaining a modeling decision | ”We’re using linked events for the fee-plus-payout flow so a partial failure can’t leave the fee deducted without the payout completing.” |
| Describing a reliability guarantee | ”Deterministic simulation testing caught that edge case before it ever touched real transfers — that’s the main reason we trust the failover logic.” |
| Discussing a hold/capture flow | ”The pre-authorization is a two-phase transfer — the hold and the final charge are two distinct, auditable steps, not one opaque update.” |
Поширені помилки
- Використання « balance update », коли ви маєте на увазі ** transfer ** — TigerBeetle не має прямої мутації балансу; кожна зміна балансу відбувається через незмінний, подвійний запис.
- Розгляд ** двофазного перенесення ** як додаткового бухгалтерського обліку — для утримання і попередніх авторизацій, пропускаючи очікуваний стан, вилучається слід аудиту «зарезервований, але ще не захоплений»
- Припустимо, що ** пов’ язані події ** поводяться як обгортка транзакції бази даних у традиційному сенсі — вони ланцюгують конкретні перенесення атомарно, а не довільною логікою програми.
Практичні вправи
- Поясніть двома реченнями, чому підрахунок з подвійним записом робить приховування помилок складнішим, ніж приховування помилок у одній змінній колонці балансу.
- Напишіть короткий опис PR для додавання двофазного перенесення для моделювання потоку передавторизації і захоплення.
- Сформулюйте повідомлення, в якому пояснюється інженеру, який не займається фінансовими технологіями, чому детерміністичне тестування моделювання має значення для надійності фінансової книги.
Зв’язані ресурси
- Англійська для розробників VictoriaMetrics
- Англійська для розробників OpenFGA
- Англійська для розробників баз даних Xata
Наприклад, англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська
Як розробники, що працюють з ядром TigerBeetle - подвійним записом, бухгалтерськими книгами і детерміністичним моделюванням - чітке спілкування є * абсолютно критичним *. Нерозуміння щодо дебетів, кредитів і пов’ язаних подій може швидко призвести до помилок у ваших моделях даних і тестуванні. Цей розділ присвячено уточненню конкретного словникового запасу, який використовується в обговореннях нашої команди, виходячи за рамки буквальних перекладів і враховуючи нюанси професійної англійської, пов’ язані з фінансовими системами. Ми розглянемо формулювання, що сприяє ясності і точності при обговоренні логіки транзакцій, сценаріїв тестування і дизайну баз даних.
Поширеною проблемою є припущення, що кожен розуміє наслідки «дебету» проти «кредиту». Це не просто про додавання або віднімання; це про *вплив * на балансовий звіт в певний спосіб. Нам потрібно постійно використовувати такі терміни, як «збільшити рахунок активів», «зменшити зобов’язання», і чітко сформулювати логіку, що лежить в основі кожної операції. Аналогічно, під час обговорення пов’ язаних подій — критичних для детерміністичного моделювання — ми повинні уникати нечітких тверджень на зразок « це впливає на те ». Замість цього, ми будемо прагнути до таких фраз, як « ця подія викликає каскадний ефект, що призводить до коригування балансу бухгалтерської книги за допомогою правила X » або « наступна подія залежить від завершення цієї події, створюючи щільно пов’ язану послідовність ». Крім того, обговорення * обґрунтування * за тестовим випадком — чому певний вхід дає певний вихід — вимагає ретельного формулювання. Замість того, щоб сказати «це не вдається, тому що…», ми повинні використовувати такі фрази, як «Ця помилка вказує на невідповідність у розрахунку дебет/кредит за сценарієм Y», або «Модель відхиляє через неправильне відображення між пов’язаними подіями»
Ці невеликі зміни значно зменшують неоднозначність і покращують співпрацю. Розгляньте, як звучать наші PR-описи - вони не просто стверджують, що * сталося *, але пояснюють * чому * це сталося в контексті правил реєстру. Нам потрібно бути в змозі чітко сформулювати потік транзакцій, логіку, що керує ними, і як ці правила відображаються в нашому дизайні бази даних.
Ось приклад використання tigerctl для тесту моделювання:
tigerctl run --simulation-test "ledger_balance_update:scenario_3" --input "initial_balance=1000, debit_amount=500, credit_amount=200"Ця команда демонструє точність, яка потрібна при описі тесту моделювання — ми не просто кажемо « запустити тест »; ми вказуємо точно, які дані використовуються для отримання детермінованого результату і як цей результат впливає на бухгалтерську книгу. Послідовний і точний словник є ключем до забезпечення цілісності нашої системи.