Available · Rionegro, CO · GMT-5 · 10+ yrs

Gian Barboza — Senior Backend Engineer & Software Architect

Designing and building backend systems, distributed architectures and payment platforms for production.

Hands-on: I design the architecture and write the code that runs in production.

Developer → CTO → Senior Backend Engineer & Software Architect

A decade of designing, building and evolving production systems across payments, distributed infrastructure and automation.

Nov 2023 — Present

Senior Backend Engineer Current

Hablax Inc. · 100% Remote

Leading AI-driven initiatives on the gift cards and top-up platform: AI-generated programmatic SEO, fraud detection engine with extensible rules, gateways to modernize legacy services, and a multi-channel notification orchestrator.

Apr 2023 — Nov 2023

Full Stack Engineer · Freelance

Independent clients · Remote

Built an end-to-end digital-goods e-commerce with a modern stack: Next.js, TypeScript, Clean Architecture and Vitest. Full Stripe and PayPal integration, delivery automation, and custom admin system.

Dec 2017 — Apr 2023

Full Stack Developer → CTO

Hablax Inc. · 100% Remote

Grew from developer into CTO leading a team of 4 developers. Designed the migration from monolith to an 8-server distributed infrastructure on DigitalOcean, integrated the core payment processors (PayPal, Payeezy, DLocal), and built the multi-provider product engine with automatic failover.

Jan 2016 — Mar 2017

Java Software Developer

Fermat.org · 100% Remote

Built P2P Android apps on top of cryptocurrencies (taxi, e-commerce) where payments landed directly in the provider's wallet with no intermediaries. First exposure to decentralized systems and 100% remote work.

Numbers that shipped to production.

A few metrics that summarize a decade of decisions.

10+
Years of Experience
99.9%
Uptime on Critical Infrastructure
$200K+
Transactions Processed / Month
5+
Payment Providers Integrated

Four production systems, and the decisions behind them.

Open any card for the context, the problem, the architecture decision, and what it changed in production.

Context
Global gift cards and top-up operation where relying on a single gateway leaves gaps in geography, conversion, and availability.
Problem
Each gateway covers different countries at different fees, and any of them can go down or start rejecting more without warning. On top of that, every provider ships its own API shape — integrating them one by one would have scattered provider-specific code across the platform.
Architecture

Every provider sits behind a single payment contract. Each integration adapts its own API — different auth, field names and error shapes — into normalized request and response objects, so the rest of the platform charges, refunds or voids without knowing which processor is on the other side.

Selection and behaviour are decoupled through design patterns: a Factory resolves which integration to build, Strategy lets each provider carry its own behaviour behind the shared contract, Adapters absorb the per-API differences, a Builder assembles the more complex provider requests, and a Repository keeps transaction persistence out of the payment logic. Routing is configuration, not code — active provider and priority chain per product — with automatic failover when the active one fails or rejects. Five processors integrated end to end (PayPal, Payeezy, DLocal, Stripe, Shift4) with 3DS, refunds, voids, Apple Pay, Google Pay and in-house card tokenization.

Result
5 payment providers behind one contract. Continuous availability during provider incidents. Routing optimized for cost and conversion.
StripePayPalDLocalShift4PayeezyPayment Routing3DSApple PayGoogle PayTokenization
Context
Payments platform exposed to two fraud vectors: transactional (stolen cards, suspicious patterns) and access-level (multi-accounts, account-takeover attempts).
Problem
New fraud patterns appeared faster than the pipeline could absorb them: every rule meant editing the central evaluator. And detecting suspicious accounts or devices could not come at the cost of friction for legitimate users.
Architecture

Separated the evaluator from the rules. A Factory builds each rule, every rule owns a single responsibility, self-registers, and receives an already-normalized context — so adding a pattern means adding a class, never editing the engine. Access fraud runs as its own layer on device fingerprinting, keeping session signals (multi-account abuse, account takeover) out of the transactional path.

Also prototyped contextual evaluation with an LLM through n8n, imitating how support agents decide. It worked at low volume and was shelved on purpose — the per-decision model cost did not survive production scale.

Result
Hours to ship new rules instead of weeks. Significant reduction in manual review load.
Factory PatternSRPDevice FingerprintingRules Enginen8n
Context
Gift cards and top-up platform processing ~1,000 transactions/day and $100K–$300K in monthly volume — all of it on a single server.
Problem
An availability problem, not a throughput one. The calling system consumed every resource on the box, so traffic spikes on Mother's Day and New Year's Eve took the whole platform down for ~3 hours — on the most lucrative dates of the year.
Architecture

Redesigned it as an 8-server distributed architecture on DigitalOcean, separating web, database and dev tiers so no workload could starve another. HAProxy for HTTP load balancing, MySQL master-slave replication for read capacity and standby, node-level failover, automated backups and recovery runbooks.

The trade-off: the legacy stack could not be provisioned automatically, so the topology was built by hand over Linux — slower to stand up, but it removed the single point of failure without rewriting the application first. Led a team of 4 through the migration.

Result
99.9% uptime sustained since 2019. Zero outages on peak dates over the last 5 years.
MySQL ReplicationHAProxyDigitalOceanNginxLinux
Context
Thousands of dollars in monthly paid-ad spend, with a catalog of 1,600+ products per provider multiplied across multiple countries and services.
Problem
Cut the dependency on paid acquisition without losing volume. Writing landing content by hand for thousands of country/service/product combinations was never going to happen.
Architecture
Designed it as a hierarchical pipeline rather than a one-off content dump: three tiers (country → country/service → country/service/product), each inheriting context from the one above, populated through ChatGPT-4o with prompts curated per vertical. The pipeline is event-driven — a new product landing in the catalog regenerates the affected tiers on its own, so the content surface grows with the catalog instead of drifting behind it.
Result
↓ paid spend significantly replaced with organic traffic. Better client ratio than the paid channel.
ChatGPT-4oNode.jsProgrammatic SEOAIPHP

Technical expertise.

Tools and patterns I reach for, grouped by domain.

Backend Engineering

/srv
Node.jsTypeScriptNext.jsPHPJavaREST APIs

Architecture

/arch
Distributed SystemsHigh AvailabilityClean ArchitectureDesign PatternsGateway PatternAPI Design

Infrastructure

/infra
LinuxHAProxyNginxMySQL ReplicationDigitalOceanCronjobs

Payments & Risk

/pay
StripePayPalDLocalShift4PayeezyPayment RoutingFraud EnginesDevice FingerprintingPCI Compliance

Automation & AI

/ai
n8nLLM IntegrationAI-Assisted DevelopmentProgrammatic SEOContent AutomationWeb Scraping
— Let's work together

Open to Senior Backend Engineer & Software Architect roles
in backend systems, distributed architecture & payments.

Available full-time and remote, for production systems with real technical constraints. Fastest reply via email or LinkedIn.

Download résumé