Startsida / Blogg / Teknik

Journalen som håller delade utgifter exakta

29 augusti 2026 · 8 min läsning · Dimesum Engineering

Ett saldo bör vara en projektion du kan slänga och bygga om, och det är maskineriet som gör det säkert: nollsummejournaler, redigeringar som bokför rättelser och en outbox som levererar i commit-ordning.

Ett saldo som du räknar upp är ett saldo som glider. Dimesum räknar aldrig upp något. Varje utgift bokförs som en dubbel bokföringspost vars poster summerar till exakt noll, och siffran på din gruppskärm är en projektion över dessa poster som vi kan radera och bygga om med ett enda kommando.

Du kan pröva det påståendet. När det enda sättet som pengar rör sig på är en journal som bara kan läggas till, slutar ett felaktigt saldo att vara ett mysterium och blir i stället en fråga som vi kan köra.

Saldon är en projektion, inte en siffra du räknar upp

Dimesums liggare äger tre tabeller: journals, postings och en balances-projektion som nycklas på grupp, medlem och valuta. Posterna bär sanningen. En post är positiv när en medlem har lagt in pengar i gruppen och negativ när medlemmen har förbrukat värde, så ett saldo är en enkel SUM(amount_minor). Projektionen finns för snabbhet, inte för auktoritet: den skrivs inuti journalens egen transaktion, och att posterna är fullständiga håller den slängbar.

Två lager hävdar samma nolla, och inget av dem räcker ensamt

I Go vägrar buildPostings att öppna en transaktion om inte postuppsättningen summerar till noll. I Postgres kontrollerar en uppskjuten villkorstrigger på nytt SUM(amount_minor) = 0 per journal vid commit, eftersom poster läggs in en rad i taget och en kontroll per rad skulle avvisa varje journals första ben. Assert-kontrollen fångar ett fel i kalkylatorn. Triggern fångar en skrivare som aldrig anropade den.

Ett tredje lager är en behörighet. UPDATE, DELETE och TRUNCATE är återkallade från rollen ledger_app på båda tabellerna, så felaktig kod kan inte skriva om historiken ens när den försöker.

En redigering bokför en återföring, aldrig en UPDATE

Att redigera en utgift skriver ingenting över den gamla versionen. Liggaren konsumerar en expense.amended-händelse och bokför två journaler i en enda transaktion: en EXPENSE_REVERSAL vars poster är den exakta negeringen ben för ben av den version som ersätts, och sedan en ny EXPENSE för den nya. En radering stannar efter återföringen.

Att det är en transaktion spelar lika stor roll som de två journalerna. Om återföringen committades ensam skulle en grupp under en kort stund vara skyldig ingenting för en utgift som den fortfarande är skyldig.

Båda idempotensnycklarna härleds ur versionen i stället för att myntas: expense:<id>:v<n> för versionen, och den föregående versionens nyckel plus :reversal för negeringen. journals.idempotency_key är UNIQUE, så en händelse som levereras på nytt hittar sina journaler redan där och gör ingenting. Härledningen är det som gör leverans minst en gång säker: ett nytt försök beräknar samma nyckel som det första försöket använde.

En vattenstämpel i commit-ordning håller en ändring bakom sin utgift

Varje händelse som Dimesum publicerar skrivs till en outbox-tabell i samma transaktion som affärsskrivningen. Om utgiften committas finns tillkännagivandet. Om den rullas tillbaka gör tillkännagivandet det också. Liggaren får aldrig höra om en utgift som inte finns.

Leveransordningen är den svårare halvan. Id:n är UUIDv7 och sorteras efter tid, men de kodar när id:t myntades, inte när dess transaktion committades. En relä som läser i id-ordning kan hoppa förbi en transaktion som tog ett tidigare id och committades senare, så en ändring går om utgiften den ändrar.

Lösningen är en kolumn och ett predikat. Varje outbox-rad bär inserted_xid xid8 DEFAULT pg_current_xact_id(), och reläet läser bara rader WHERE inserted_xid < pg_snapshot_xmin(pg_current_snapshot()), sorterade efter det xid:t (se PostgreSQLs funktioner för transaktions-id). En kausalt senare händelse bär alltid ett senare xid, eftersom den var tvungen att läsa den tidigare raden för att finnas.

Ändringskonsumenten tar inte den ordningen på förtroende. En ändring vars föregångare saknar journal levereras på nytt medan den är ung, och parkeras för en människa när den har passerat en respit på två minuter.

Pengar är int64 minorenheter, och exponenten är inte alltid två

Varje belopp är ett int64-antal minorenheter plus en ISO 4217-kod, så 1 234,56 kronor är {Minor: 123456, Currency: "SEK"}. Heltal är exakta genom sin konstruktion, inte genom disciplin: inget representerbart värde är ett halvt öre, så ingen operation kan tyst skapa ett. Python-sidovagnen läser sin egen AST och underkänner ett test om ordet float förekommer i dess beloppsmodul.

Att anta att minorenheten är en hundradel är fällan som ligger under. JPY har ingen alls och KWD har tre decimaler, så en kurs som anges mellan majorenheter och tillämpas på minorenheter blir fel med en tiopotens. Ta 2 000 yen till 0,58: den naiva produkten är 1160, vilket läses som 11,60 kronor, medan svaret är 1 160.

WRITE_OFF är en femte journaltyp eftersom dess poster är samma som en avräknings

En avskrivning bokför samma två ben som en avräkning gör: gäldenären stiger, borgenären faller, med samma belopp. Att slå ihop den med SETTLEMENT avvisades av exakt samma skäl som gör att formerna stämmer. ”Asha betalade dig 500 kronor” och ”du efterskänkte Asha 500 kronor” är olika fakta, och ett flöde som blandade ihop dem skulle påstå att någon betalade när ingen gjorde det.

Så WRITE_OFF anslöt sig till journaltypens CHECK den 2026-08-21, med egna ben. Att namnge dem var halva poängen, eftersom en avskrivning som återanvände SETTLE_PAY skulle göra varje fråga om ”hur mycket som faktiskt har betalats” tyst felaktig.

Två underkommandon gör invarianterna till ett cron-jobb

evenly verify-ledger bevisar invarianterna på nytt över hela schemat och avslutas med skilt från noll vid varje träff. Dess rapport har fyra fält, och vart och ett förväntas vara tomt: journaler som inte summerar till noll, grupper som inte summerar till noll, projektionsrader som avviker från en omräknad SUM(postings), och parkerade händelser som väntar på en människa. Alla genomsökningar delar en enda repeatable-read-ögonblicksbild, så en journal som landar mitt i verifieringen kan inte hitta på en avvikelse.

Varje genomsökning grupperar efter valuta lika väl som efter id, och felet som det undviker är ett falskt negativt. En post på 500 kronor och en på minus 500 yen summerar till noll när en fråga ignorerar valutakolumnen, så en dubbelt korrupt liggare skulle framstå som ren.

evenly rebuild-balances [group-id] är både reparationen och övningen. Den tömmer projektionen och räknar om varje rad från posterna, och stämplar var och en med den senaste journalen som rörde den medlemmen, precis som den direkta skrivningen gör. Likhet rad för rad är egenskapen: när en ombyggnad och den direkta projektionen inte stämmer överens är liggaren den som har rätt.