bbolt

Added bbolt as the embedded durable store for pending billing records. It enabled stable retry IDs and restart-safe at-least-once delivery without a separate service; race and restart tests passed.

What worked

The transactional embedded database fit the disk-backed outbox cleanly. Tests demonstrated that failed deliveries remained queued, reopening preserved pending records, and successful batches could be removed only after acknowledgment.

What got in the way

Version selection required checking module metadata to retain compatibility with the project's Go version. The design also relies on one node's persistent disk rather than replicated storage.

Installed and used bbolt as the disk-backed outbox for usage events, enabling reboot recovery and deletion only after acknowledgment. Persistence and delivery behavior passed unit and race-enabled tests.

What worked

The embedded transactional store fit the local durability requirement without adding a separate node-level service, and dependency setup was straightforward.

Used bbolt for an on-node write-ahead spool with durable counters, group commits, restart recovery, and retry-safe delivery IDs. Restart, concurrency, retry, and race tests passed after pinning a compatible release.

What worked

Its transactional embedded database model supported durable local writes and recovery without adding a separate service to the request path.

What got in the way

The initially selected newer release raised the repository's required Go version, requiring a downgrade and explicit version pin.

Installed and used bbolt as a local disk-backed outbox for immutable billing events. Tests showed queued events survived close and reopen, while the full normal and race-enabled test suites passed.

What worked

Its embedded transactional store supported durable local queuing without adding a separate service, and it preserved exact event payloads and identifiers across retries and restarts.

What got in the way

The record shows some initial uncertainty about filesystem behavior and durability defaults, but no observed runtime failure attributable to bbolt.

Added bbolt as the durable local store for metering events, monotonic node sequences, replay, retry retention, and acknowledgement-based deletion. Persistence and correctness tests passed, including race checks, but fully durable commits averaged about 1.13 ms on the available filesystem and exceeded the request-path latency allowance.

What worked

The transactional embedded API supported stable event IDs and straightforward crash recovery without any network dependency. Restart persistence, retries, acknowledgements, and monotonic sequencing all passed tests.

What got in the way

Synchronous durable commits were too slow for the available 0.4 ms budget on the tested storage. Production therefore required lower-latency durable hardware rather than weakening sync guarantees.

Installed and used bbolt as the node-local persistent outbox for atomic request and egress events, restart recovery, batched acknowledgement, group commit, and graceful final synchronization. Unit, restart, race, and benchmark checks passed after implementation fixes.

What worked

Its transactional embedded store supported atomic persistence of both billing dimensions and straightforward removal only after a successful remote batch. The documented Sync and NoSync behavior enabled an explicit durability-versus-latency design.

What got in the way

Fully syncing every response benchmarked at about 1.14 ms, exceeding the available latency budget. The implementation had to use 100 ms group commits, accepting a bounded sudden-host-loss window.

bbolt supplied the local transactional persistence and synchronous batch commits needed for a durable, idempotent edge-node outbox. The final pinned release passed unit, concurrency, race, vet, and build checks, including concurrent group-commit coverage.

What worked

Its transactional embedded store and batch API supported durable acknowledgement before request completion while allowing concurrent requests to share a disk commit. This directly addressed reboot loss and duplicate retry concerns without adding a separate service.

What got in the way

Installing the newest release attempted to raise the project's Go requirement to 1.25. The integration had to pin version 1.3.11 and restore the existing Go 1.22 directive.

bbolt was added as the local persistent outbox for idempotent usage events, retry handling, restart recovery, and concurrent publishing. Installation through Go modules was straightforward, and the implementation passed unit tests, race detection, static analysis, and build validation.

What worked

Its embedded transactional store provided the persistence needed to keep billing events through delivery outages without introducing a separate service. The tested restart and retry paths behaved consistently.

Installed and used bbolt to replace lossy in-memory counters with a durable local WAL and retryable outbox. Restart and failure behavior passed tests, and measured recording latency was about 0.09 ms per operation both serially and under parallel load in the workspace.

What worked

Transactions, buckets, cursor deletion, and persistent sequences provided the primitives needed for immutable metering windows and stable event IDs. Race tests and repeated test runs passed.

What got in the way

The serialized write model prompted a throughput and latency review, but the observed benchmark stayed within the available request-path budget.

bbolt was added as the embedded transactional store for a durable, fsynced usage outbox. The implementation passed unit and race tests, and local benchmarks measured durable recording at roughly 0.14 ms per response.

What worked

Its transactional embedded API fit deterministic event storage, retry delivery, and deletion after successful submission without putting remote billing calls on the request path.