Argentina — open to remote
Backend engineer with nearly five years of experience, currently leading backend for production systems. I work across development, multi-stage environments, QA, and production releases—not just the final deploy. I care about data consistency, concurrency, clear API contracts, and trust boundaries that hold up in the real world.
I’m especially strong in transactional booking, payments, and identity—but that sits inside a broader practice: architecture, safe product evolution, and systems that stay observable and operable.
Systems running in production where I own or lead backend work. For the long technical version, open a project page.
Production project
Django · PostgreSQL · payments & catalog integrations
Tourism bookings in production: reservations, payments, multi-tenant backoffice, and integrations with payment providers and an external activity panel. The backend is where we enforce transactional rules, safe webhook handling, and releases through staging and QA—not only the prod deploy.
ContextBusiness rules needed identifiers scoped by activity: global mapping let the same modality leak across unrelated activities.
What I didMoved to scope-aware mapping, pushed critical uniqueness into the database with conditional constraints where legacy data still had to live, and used additive migration plus explicit legacy fallback order.
ImpactFewer cross-activity data bugs and a defensible story under concurrency—validators are not enough if the DB cannot enforce the rule.
ContextTags, replace-style assignment APIs, and an external panel that bills per line: technically valid payloads still broke commercial semantics.
What I didModeled tags as a real M2M, made update semantics explicit (replace vs incremental), kept backward compatibility during rollout, and used decision-oriented logging plus payload audit when the integration mispriced.
ImpactCatalog and admin flows got clearer contracts; we caught a billing-side semantic mismatch quickly and corrected the mapping instead of debating HTTP 200 forever.
ContextMany services needed one citizen identity without each system re-calling national registries or duplicating verification.
What I didCentral gateway issues tokens; downstream services validate and apply RBAC only. Minimal claims in tokens, fail-safe when national APIs are unavailable, audit on sensitive paths.
ImpactOne trust boundary instead of many implicit ones; easier reasoning about security and compliance at interview depth.
ContextPayment initiation and webhooks must stay correct under retries, duplicates, and overlapping writes.
What I didRequired idempotency keys for initiations, outbox-style separation for provider calls, webhook handling idempotent by provider event id, tight transaction boundaries per state transition.
ImpactDuplicate events and client retries become safe paths instead of incident generators—matches what senior roles expect you to articulate.