Giuliano Bentevenga

Argentina — open to remote

Senior Backend Engineer focused on transactional systems, payment flows, identity gateways and strict trust boundaries. Production systems built for correctness under concurrency and failure.

Production backend engineer: hardened payment integrity against hostile inputs, moved integrations to contract-first payloads, and operated secure-by-default APIs with clear trust boundaries.

GitHub LinkedIn

Download Resume (PDF)

Executive Snapshot

•~2k reservations/month in production (patagoniadreams.com.ar).
•~45k logins/month on identity gateway (autentica.bahia.gob.ar).
•99.5% uptime on identity gateway over 12 months.
•p95 webhook-to-DB under 400 ms; 8+ backend services consume gateway tokens.

patagoniadreams.com.ar — reservation availability
Challenge
concurrent bookings for same slot, race to mark paid
Decision
SELECT FOR UPDATE on availability row; webhooks only path to "reservation paid"
Impact
double-booking eliminated; ~2k reservations/month in production.
patagoniadreams.com.ar — payment webhooks
Challenge
duplicate or replayed payloads, provider retries
Decision
HMAC validation on all webhooks; idempotency by event_id; single writer for payment state
Impact
no double-apply; retries safe; p95 webhook-to-DB under 400 ms.
patagoniadreams.com.ar — reservation creation
Challenge
duplicate submissions (double-click, client retries)
Decision
idempotency key per creation request; unique constraint on key in DB
Impact
retries safe; no duplicate reservations.
patagoniadreams.com.ar — payment and reservation state
Challenge
two states must stay in sync; frontend could not drive status
Decision
single DB transaction on webhook: create/update payment record and set reservation paid
Impact
no "paid" without webhook; no split state.
autentica.bahia.gob.ar — session token lifecycle
Challenge
who issues, who validates; avoid PII in tokens
Decision
gateway sole issuer; tokens carry only claims (sub, roles, exp); RBAC at gateway and at each service
Impact
clear trust boundary; ~45k logins/month; 99.5% uptime over 12 months.
autentica.bahia.gob.ar — identity verification
Challenge
national APIs (RENAPER, AFIP) down or high latency
Decision
never issue "verified" when verification did not succeed; degraded mode + alerting when APIs unavailable
Impact
no false "verified"; re-validation on every login.
autentica.bahia.gob.ar — legacy service integration
Challenge
legacy systems must not re-authenticate; single source of identity
Decision
gateway issues signed tokens; services validate signature and apply RBAC only; no direct calls to national APIs from services
Impact
single place for identity; 8+ backend services consume tokens.
autentica.bahia.gob.ar — authorization and audit
Challenge
role and resource access across services; who did what
Decision
RBAC at gateway (route-level) and at service (resource-level); roles in token claims; DB constraints and audit logging for sensitive actions
Impact
consistent policy; full audit trail for compliance.

Case Study

Transactional Booking & Payment Platform

Payments • Webhooks • Concurrency

View live site

Tourism reservation platform in production. Multi-module, multi-tenant backoffice (partners and end customers). Payments via Mercado Pago, Stripe, Pix; webhooks as single source of truth for "reservation paid," with HMAC validation and idempotency by event_id. Idempotency keys on reservation creation; promotion engine with transactional claims; catalog normalization with external providers. Modular monolith, Docker, CI/CD, AWS. Transactional integrity and payment security by design.

Transactional Flow Overview

Internal System

System Invariants

·A payment intent cannot transition from failed to succeeded.
·Reservation "paid" is set only after a verified webhook; frontend and redirect cannot set it.
·Webhook events are processed idempotently by provider event_id.
·Availability for a slot is updated under pessimistic lock (SELECT FOR UPDATE); no optimistic commit.
·Idempotency keys are scoped per client and stored; duplicate key returns original response.
·Payment and reservation state changes for a webhook occur in a single database transaction.

Architecture Decision Records

Architecture & decisions

Production patterns and decisions presented in sanitized form (no proprietary details).

Payment integrity under hostile inputs

Context: The payment path accepted attacker-controlled signals (webhook mode flags and client-sent final price), enabling false approvals.

Decision: Enforced signature validation independently of request flags and recomputed/validated amounts server-side in checkout and webhooks.

Tradeoff: Higher validation complexity and edge cases around rounding tolerance.

Outcome: Closed direct fraud paths and prevented invalid approved states from reaching reservation status.

Contract-first integrations over text parsing

Context: Transfer details were propagated as free text, causing ambiguity and brittle downstream behavior.

Decision: Moved package transfer payloads to structured contract fields (kind + trfDetail) with strict conditional validation and normalization.

Tradeoff: More schema and validation branches to maintain across product/package flows.

Outcome: Deterministic integration behavior and cleaner end-to-end operational data quality.

Secure-by-default API posture

Context: Open permissions, verbose errors, and inconsistent endpoint controls increased exposure risk.

Decision: Set authenticated defaults globally, added scoped throttling for sensitive routes, and moved technical detail from client responses to internal logs.

Tradeoff: Tighter operational discipline and occasional contract adjustments in endpoint responses.

Outcome: Lowered PII exposure and abuse surface while improving resilience under noisy traffic.

Explicit Tradeoffs

Webhooks as single source of truth for "paid".
Gained: No frontend or redirect driving state; provider is authority. Double-apply impossible by design.
Sacrificed: User waits for webhook; we depend on provider delivery and our endpoint availability. No instant "paid" from redirect.
Pessimistic lock (SELECT FOR UPDATE) on availability.
Gained: No double-booking; deterministic behaviour at consistency boundary.
Sacrificed: Throughput on hot slots limited; lock contention under load. No optimistic retry path.
Modular monolith over microservices.
Gained: Single deployment, single DB, transactional consistency. Lower operational cost.
Sacrificed: Cannot scale domains independently. One bug or deploy can affect all. Must scale the whole app.
Gateway as sole issuer of tokens; legacy systems validate only.
Gained: One trust boundary. Legacy systems do not touch identity APIs or PII.
Sacrificed: Gateway is single point of failure for login. All login traffic through one component.
Idempotency keys at application layer.
Gained: Safe retries; no double charge or double reservation. Client and webhook duplicates are no-ops.
Sacrificed: Client must supply or we derive key; key storage and TTL; more complexity than fire-and-forget.
No PII in tokens; minimal claims only.
Gained: Blast radius limited on token leak. Compliance boundary clear.
Sacrificed: Services cannot display user details without calling gateway or user store; extra round-trips or caching.
Synchronous audit log write in critical path.
Gained: No lost events on crash. Guaranteed audit trail.
Sacrificed: Added latency and write load; log storage grows. No async fire-and-forget for audit.

PostgreSQLDjango REST FrameworkDockerCI/CDGitHub ActionsAWSStripeMercado PagoCognito