Backend Engineering
We build the event ledgers, state machines and APIs that never lose a record or an explanation. Every event we touch is recorded exactly once by construction, idempotent by contract, and replayable from the first byte to the last. When an auditor asks "what happened to this record three months ago", our answer comes from an immutable audit log — not from someone's memory.
Deploys per day, trunk-based
MTTR on data incidents
Unreconciled ledger rows in 24h
Availability floor on platform APIs
Why Backend
Data integrity is the one place "mostly works" is unacceptable
A frontend bug is embarrassing; a backend bug is somebody's data. We engineer accordingly: every state change is an immutable event by construction, so the record and its projections cannot disagree even under partial failure; every external call is idempotent by contract, so a retried request cannot write a record twice; every state transition lives in a durable workflow engine, so a crash mid-flow cannot leave a workflow half-committed. We model in events before we model in tables, because the audit log is the spec and the schema is a derived view of it. The ledger is not a side effect of the product — it is the product.
We do not trust ORMs with critical data, because abstractions that hide SQL also hide the off-by-one that corrupts a customer's ledger. Our transactional core is written in a language whose type system expresses quantities as non-float primitives; our read path is a separate concern, replicated and indexed for queries that would otherwise pin the write buffer. Every service ships with a contract test that proves the API does what the OpenAPI spec says it does, and every breaking change routes through expand–contract migrations so production never sees a deploy that breaks a client at the same moment it ships. When something does go wrong — and it does — the audit log is replayable, the reconciliation job catches the discrepancy within the hour, and the runbook is the one a human wrote at 3am last month.
What we build
The transactional core of every FiduciaWay platform lives here. Here is what we own end-to-end.
Records & Approval Engines
Immutable records with multi-party approvals and a policy engine that enforces your rules — every view, edit and signature on one auditable trail.
Immutable Ledgers
Append-only, cryptographically chained, replayable from genesis to today. The ledger is the source of truth; everything else is a derived view that can be rebuilt on demand.
Integration Rails
Idempotent, retryable and reversal-aware integrations with ERPs, CRMs, warehouse systems and partner APIs — built for systems that lie, lag and lose, and verified against them.
Reconciliation Jobs
Source-vs-bus-vs-target reconciliation runs hourly; any discrepancy pages an engineer, not a Slack thread. The job that catches the missing record is more important than the feature that shipped a million.
Contract-First APIs
OpenAPI-first, semantically versioned, contract-tested with Pact on every PR. A breaking change that survives CI survives it because it followed expand–contract, not because we got lucky.
Durable Workflows
Long-running transactions and state machines live in Temporal, so a process crash mid-workflow resumes from the last completed step — not from the beginning, and never from a half-state.
How we work
Our loop is event-driven and contract-first. Here is one orbit, from storm to canary.
Model in events
We event-storm the domain before we touch a database. The audit log is the spec; the schema is a derived view of it.
Write the contract first
The OpenAPI spec lands before the implementation; the frontend co-signs it. A schema change without a co-signed contract does not merge.
Implement against tests
Unit, property-based, and contract tests run on every commit. Critical flows get property-based tests that hammer invariants over thousands of random inputs.
Review for idempotency
Every external-boundary handler is reviewed specifically for idempotency, retry semantics and compensating-action paths — the failure modes that hurt data integrity.
Migrate expand–contract
Schema changes ship as expand first, contract later — never both at once. A breaking column removal is a separate PR weeks after the new code stops reading it.
Ship behind a canary
Deploys are progressive: 1% then 10% then 100%, with automated rollback on SLO breach. The deploy that fails a critical-flow test is reverted before a human reads the alert.
Definition of done
A critical flow ships only when all of this is true
Idempotent
Every external-boundary handler has an idempotency key and a property-based test proving retries are safe.
Audited
Every state change writes to an append-only, cryptographically chained ledger — replayable on demand.
Migrated safely
Schema changes follow expand–contract; the rollback path is tested before the forward path ships.
Load-tested
Critical paths are load-tested with realistic data and at peak × 3; p99 latency stays inside the SLO envelope.
Documented contract
OpenAPI spec updated, contract tests green, and the on-call runbook updated by the engineer who wrote the code — not by someone reverse-engineering it later.
Tools & why we use them
Boring on purpose. Each tool was chosen for its failure mode, not its demo.
ACID, mature replication, and a type system expressive enough to keep quantities out of floats.
Durable execution for long-running approval workflows; a crash mid-flow resumes from the last completed step.
Append-only event log that doubles as our audit backbone and our integration bus.
The transactional core: a type system and concurrency model that make partial-failure states visible at compile time.
Service surfaces and internal tools; strict mode keeps the API shape honest across the team.
Contract-first development; the spec ships before the code, and contract tests prove both ends agree.
Structured logs linked by transaction id; any incident replays event-by-event from the audit log.
Load tests at peak × 3 with realistic data; p99 latency has to stay inside the SLO envelope or the build fails.
How we interface
Where backend meets the rest of the company
Frontend
We co-sign OpenAPI contracts; the spec ships before the code. A breaking change that the frontend cannot absorb does not merge.
DevOps
We own the SLO together; backend writes the runbook, DevOps owns the canary and the rollback lever. Neither of us ships a critical path without the other's sign-off.
QA
Property-based and contract tests are co-written; QA owns the critical-path scenario matrix that runs against every release candidate.
Data
Data exports are events off the audit log, never direct DB taps. Analytics never pins the write buffer; risk models see the same events the regulator will.
Questions we get asked
Why no ORM for critical data?
Abstractions that hide SQL also hide the off-by-one that costs a customer their rent. We use a thin query builder with explicit casting for domain primitives, and a code reviewer specifically looks for quantity-to-float coercion.
How does reconciliation actually work?
Three-way: source system vs event bus vs target response, every hour. Any discrepancy pages the on-call engineer directly — it never lands in a "we'll look tomorrow" queue.
How do migrations not break production?
Expand–contract only. The forward migration ships first and runs for weeks with both old and new code paths; the contract migration that removes the old path ships separately once telemetry proves nothing reads it.
What is on-call like?
One week primary, one week secondary, then four weeks off. Runbooks are written by the engineer who wrote the system; alerts that fire more than twice trigger a runbook-fix backlog item automatically. We do not page humans for things a job can catch.
Why a modular monolith and not microservices?
A modular monolith with extracted key-management services gives us a clear audit boundary, a single deploy to reason about, and transactional consistency where data integrity demands it — without the operational tax of a distributed system we do not need.
Our mission
Build the event ledgers and APIs that never lose a record or an explanation. We treat the audit log as the spec and the schema as a derived view of it, so that every auditor, every operator and every customer can trust the same source of truth — replayable, on demand.