Skip to content

I build backend services that stay correct when things fail, and I prove it with tests.

See how each claim is proven

The life of a webhook eventA line map. The event enters at the API, is saved in the outbox in the same database transaction, is picked up by the dispatcher, goes through the SQS queue to the consumer and then to the sender, which signs it and calls the receiver. In this example the receiver answers 500, then 500, then 200. After each failure the event rides a retry loop back to the sender. After 10 attempts, about 47 hours, an undelivered event would end in the dead-letter queue.APIOutboxsame DB transactionDispatcherSQS queueConsumerSendersigned with HMACReceiver500, 500, 200retryDead-letter queueafter 10 attempts,about 47 h200

About

I came to software through marketing and interpreting. I worked as a remote interpreter while I studied marketing, started learning to code in 2021, and kept going because the more I learned about how software is built, the more it interested me. I test everything, and when something fails I write the failure down and keep going until it passes.

More about me

Projects

Two systems built to stay correct when things fail, and two shorter lines. Every stop links to the test or document behind it.

Court Booking

A padel court booking app where a double booking is impossible by construction, not by checking first.

  1. The database refuses overlaps

    A PostgreSQL exclusion constraint on a time range rejects overlapping reservations. The API turns the violation into a 409.

  2. Twenty requests, one winner

    A test fires 20 simultaneous requests at one slot against a real PostgreSQL: exactly one succeeds and nineteen are rejected.

    Read the test for Twenty requests, one winner (opens in a new tab)

  3. Two browsers race for the same slot

    An end-to-end Playwright test races two browsers for one court slot. The court grid takes one API call per day.

The demo is in Spanish, and the first load can take a few seconds while the database wakes up.

Webhook Delivery Platform

A service that delivers webhooks to receivers that are down, slow or hostile, without losing an event.

  1. The event is saved before it is sent

    A transactional outbox with at-least-once delivery, tested with Testcontainers on PostgreSQL 18.

    Read the decision for The event is saved before it is sent (opens in a new tab)

  2. Retries for about 47 hours, then a dead-letter queue

    Ten attempts with jitter, a circuit breaker per endpoint, and SSRF protection checked at connect time.

    Read the decision for Retries for about 47 hours, then a dead-letter queue (opens in a new tab)

  3. A rolling update under load lost 0 events

    Measured in 3 runs on local Kubernetes (kind), not on AWS. The test can fail: with the shutdown window cut to 1 second it still lost 0 events but produced 45 duplicate deliveries.

    Read the script for A rolling update under load lost 0 events (opens in a new tab)

No live demo: it is a backend, so the map above and the tests are the evidence.

Shorter lines

Stack

  • Frontend

    React, TypeScript, Tailwind CSS, TanStack Query

  • Backend

    Java with Spring Boot, Python with FastAPI, Node.js with Express, PostgreSQL

  • Testing and deployment

    JUnit 5, Testcontainers, Playwright, GitHub Actions, Docker, Kubernetes, Terraform, AWS

Experience

  • Digital Developer & Marketing

    Larsen Italiana, Internship (Estadía I and II)

    Sole person responsible for the digital area. Built and deployed the bilingual React/Vite website and set up Google Search Console.

    Jun 2026 to Present

  • Remote interpreter for US clients

    2019 to present

Education

  • Bachelor’s in Marketing, Universidad Madero

    Graduating 2027

  • Full-Stack Engineer Certification, Codecademy

    Sep 2025

  • Web Development Bootcamp, DEV.F, Mexico City

    Oct 2021 to Oct 2022