Skip to content
Diego Ramírez

Backend engineer · Medellín, Colombia

I build backend systems that stay correct under load, and I write down why.

Node.js, NestJS and TypeScript on PostgreSQL. Each system below is live, tested down to its invariants, deployed from immutable images, and explained in architecture decision records.

See the workGitHub profile(opens in a new tab)

Work

Two systems, both running in production

Built as one spine: MiniLedger authorizes every write through AccessCore, the way a real platform grows. Open them, sign in with the demo account, and read the decisions behind them.

AccessCore

LiveIdentity & authorization platform

A hybrid ReBAC + RBAC + ABAC policy engine with Zanzibar-style consistency.

Relationships, IAM-style deny-override and Cedar-like conditions are resolved in one call that is deterministic, explainable, and consistent under concurrent writes. Other services authorize through its published SDK.

p50 check with the decision cache (k6)
1.3 ms
merged line coverage
~96%
architecture decision records
27
  • Consistency tokens and revision-keyed caching: a cached permit can never outlive a write or skip a step-up to MFA.
  • Zanzibar-scale work: a decision cache, a batched decision log, a Watch API over SSE, and a Leopard-style flattened membership index gated per tenant.
  • Security as the product: EdDSA tokens signed by non-exportable Vault Transit keys, refresh-token reuse detection, lockout, and a tamper-evident audit chain.
  • An admin console behind a backend-for-frontend: the browser never holds a token.
  • NestJS
  • PostgreSQL
  • Redis
  • Vault Transit
  • Drizzle
  • Next.js
  • Playwright
Live console(opens in a new tab)API reference(opens in a new tab)Source(opens in a new tab)Decision records(opens in a new tab)

The demo account is prefilled on the sign-in page. Its data resets every night.

MiniLedger

LiveDouble-entry ledger API

Money that is conserved, idempotent, and safe under concurrency.

Transfers post balanced entries between accounts, retries never double-spend, and every posting is hash-chained. It is the first consumer of AccessCore: every write is authorized through its SDK.

merged line coverage
~99%
mutation score on the ledger domain
100%
architecture decision records
14
  • Balance enforced twice: by the domain model and by a deferred sum-zero trigger in PostgreSQL that rejects an unbalanced transaction at commit.
  • Idempotency keys and ordered row locks: no double-spend on retry, and no lost update, write skew or deadlock under concurrent transfers.
  • A per-account hash chain and a conservation proof that anyone can re-run from the dashboard.
  • Browser tests run against the released AccessCore image, so a breaking change upstream turns this build red.
  • NestJS
  • PostgreSQL
  • Drizzle
  • fast-check
  • Next.js
  • Playwright
Live dashboard(opens in a new tab)API docs(opens in a new tab)Source(opens in a new tab)Decision records(opens in a new tab)

Signs in through AccessCore with the same shared demo account.

Approach

How these are built

The same bar applies to every project, and the repositories show the evidence.

Decisions are written down

Every significant choice has a decision record with its context, the alternatives, and the cost accepted. Each project ships architecture, data model, security, testing, deployment and trade-off documents.

Tests prove properties

Property-based tests state the invariants, mutation testing checks that the tests can fail, concurrency runs against real PostgreSQL, and Playwright drives the UIs. Read-only journeys run hourly against production.

Shipped like production

Images are built once in CI and deployed by commit SHA behind Traefik with TLS. Services run with least-privilege database roles, private metrics, memory limits and log rotation.

Fail closed, by design

Authorization denies when unsure, tokens are revocable before they expire, and a shared demo cannot be used to lock other visitors out. Each project carries its own threat model.

Roadmap

What comes next

Each system reuses the foundations of the previous one.

  1. AccessCore

    Live

    Identity, sessions and a hybrid authorization engine.

  2. MiniLedger

    Live

    A double-entry ledger that authorizes through AccessCore.

  3. EventBridge

    Next

    A transactional outbox relayed to RabbitMQ, idempotent consumers, and dead-letter handling.

  4. CQRS Reporting

    Planned

    Read models and projections fed by those events, with eventual consistency made explicit.

  5. LegacyBridge

    Planned

    An anti-corruption layer over flat files and legacy interfaces.

  6. Enterprise Ops Platform

    Planned

    The pieces above composed into one operable platform.