Electronic engineer and Java backend developer. I build APIs, connect REST and SOAP systems, and modernize applications for cloud environments. Experience across ERP, logistics and media platforms.
Assigned to AGEA (Clarín Group), contributing to Java microservices and a phased migration from on-premises infrastructure to Google Cloud. My work includes cloud configuration and adapting applications for the migration.
Java · Microservices · Google Cloud · Docker
02Jun 2021 — Dec 2025
NeuralSoft
Java Developer · FastPRG
Developed Java microservices for ERP and logistics platforms and real-time communication using WebSockets on Tomcat. Containerized legacy services and supported Linux servers and CI/CD workflows.
Java · Tomcat · WebSockets · Docker · Linux
03Jul 2019 — Mar 2021
Ingeniería Boggio
Software Developer
Researched and built a web chatbot with Python and Rasa, deployed on Google Cloud. Created a Flask and PostgreSQL web tool to manage bot training.
Python · Rasa · Google Cloud · Flask · PostgreSQL
02 / SELECTED WORK
Backend engineering in practice.
PERSONAL PROJECT · IN DEVELOPMENT
SecurePay /
A Java and Spring Boot payment API exploring reliable payment processing. The repository includes PostgreSQL persistence, authentication, Docker Compose, health checks, OpenAPI documentation and security design notes.
The design separates a failed payment from an unknown result. A timeout requires reconciliation before another charge. Idempotency keeps repeated requests tied to the same operation. This is a learning project, with no production payment processing.
DESIGN NOTES
payment.request idempotency_key status: PENDING confirmation: required retry: same operation
03 / ENGINEERING CASE
A timeout is an unknown outcome.
SecurePay · Design case from a personal learning project.
01 / PROBLEM
Did the payment go through?
A payment provider may process a charge even if its response arrives too late. Creating a new charge after a timeout can produce a duplicate payment.
02 / DESIGN DECISION
Keep the same operation.
Use an idempotency key to identify the request. The planned provider flow keeps uncertain outcomes UNKNOWN and reconciles them before another charge is considered.
03 / TESTS & NEXT STEPS
Make the evidence visible.
Existing tests cover sequential request replay and conflicting payloads using an in-memory database (H2). PostgreSQL concurrency tests and provider timeout reconciliation remain planned work.
Test code is available for review; PostgreSQL concurrency and provider timeout scenarios have not yet been demonstrated. No production payment processing or measured production outcomes are claimed.
04 / WORK WITH ME
Find the next step for your Java system.
An initial diagnostic for teams dealing with integration issues or planning to modernize an existing application.
INITIAL ENGAGEMENT
Java & integration diagnostic
We start with one application or integration and a specific problem: failed requests, retries, communication between systems, or deployment obstacles.