Backend engineer
who builds distributed systems
that don't break in production.
I help SaaS teams ship reliable distributed backends. NestJS, TypeScript, AWS, event-driven architectures.
Three things I do better than most.
Backend APIs that scale
Production-grade REST and GraphQL APIs with NestJS and Node.js. Multi-tenant, well-tested, observable. The kind of code your team can build on for years.
Event-driven architecture
Async workflows, the Outbox Pattern, idempotency, retries that actually retry. For when "send and pray" stops being good enough for your business.
Production firefighting
Race conditions, duplicate records, jobs failing silently, slow queries. I diagnose the bugs nobody on your team has time to fix — and add the observability to catch the next one.
Problems solved, measured in production.
Case 01 · 2025 Distributed Notification System with the Outbox Pattern
Multi-tenant SaaS · GraphxSource
The problem
Critical events were being lost in transit. Silent failures, no traceability, customers complaining.
What I built
Outbox Pattern with async dispatcher, transactional persistence, retries with exponential backoff, and distributed tracing.
Case 02 · 2025 Fault-Tolerant Order Processing
High-volume transactional system · GraphxSource
The problem
Orders failing on transient errors. Race conditions. Engineers manually reprocessing every week.
What I built
Retry system with idempotency, partial indexes, pessimistic locking, and server-side billing validation.
Case 03 · 2024 iOBOT — Omnichannel CRM Backend
B2B SaaS · Authcode
The problem
Unify WhatsApp, Instagram and Messenger into a single CRM pipeline, real-time, at scale.
What I built
Event-driven workflows on AWS, Socket.io for real-time, plus an OpenAI chatbot layer for repetitive flows.
Products I helped ship at Authcode — live, in the wild.
A backend engineer who cares what happens after deploy.
I'm David Martínez, a backend engineer based in Honduras with 4+ years shipping distributed systems to production. My focus is the unsexy stuff that decides whether a SaaS survives its first 1000 customers: reliability, idempotency, observability, and graceful failure. See it in selected work.
I prefer working in small, testable increments, writing code that the next engineer can debug at 2am, and being honest when a problem needs more than a quick fix. The kinds of problems I take on are listed under services. I communicate clearly in English, ask the questions nobody else is asking, and ship.
When I'm offline I'm usually on a football field. Available 20–30 hrs/week for the right project. Based in CST, comfortable with US and EU timezones — get in touch or grab my CV.
// Languages & Runtime
CSS / Frontend // Backend & APIs
Next.js // Data & Infra
// Architecture
// Observability & Testing
Common questions.
What kind of backend work do I specialize in?
I build production-grade backend systems for SaaS: NestJS and TypeScript APIs (REST and GraphQL), event-driven architectures with the Outbox Pattern, AWS infrastructure (SQS, Lambda, RDS, S3), PostgreSQL, Redis, and observability with OpenTelemetry. My focus is reliability, idempotency, and graceful failure — the engineering work that decides whether a SaaS scales past its first 1000 customers.
How many years of experience do I have?
4+ years building and shipping distributed systems to production. Recent work includes a multi-tenant notification system I built with 99.9% event delivery reliability and a fault-tolerant order processing system that reduced processing failures by 40%.
Am I available for freelance or contract work?
Yes. I'm available 20–30 hours per week for the right project. I'm based in San Pedro Sula, Honduras (CST, UTC-6) and comfortable working with US and EU timezones. We start with a free 20-minute call to assess fit.
What is the Outbox Pattern and why do I use it?
The Outbox Pattern is a reliability technique for distributed systems: I persist events to a database table in the same transaction as the business write, then dispatch them asynchronously from a separate process. This guarantees events are never lost on transient failures, network blips, or service restarts. It's the difference between 'send and pray' and 99.9% event delivery in production.
How do I approach observability?
I use distributed tracing with OpenTelemetry, structured logging with Pino, metrics for retry behavior and queue depth, and dashboards for end-to-end latency. My goal is that when something fails at 2am, the next engineer can diagnose it without paging anyone.
What technologies do I use most?
Daily: NestJS, TypeScript, Node.js, PostgreSQL, AWS SQS, Redis, Docker. Regularly: GraphQL, TypeORM, Lambda, S3, RDS, OpenTelemetry, Jest. Architecture patterns I use most: event-driven, microservices, Outbox Pattern, multi-tenant.
How do we start working together?
Book a free 20-minute call with me at https://cal.com/davidmrtz/20-min-call or email contact@davidmrtz.me. I respond within 24 hours and will tell you directly whether I'm a fit for the project.
Got a backend problem
worth solving?
Tell me what you're building. If I'm the right fit, you'll know in our first call. If I'm not, I'll tell you that too.
