Good afternoon — 00:00 PM where you are.
Staff Software Engineer / Technical Lead
I turn product challenges into reliable systems designed to scale.
From architecture to operations, I connect technical decisions to the experience they support.
How I work
I start with the product problem, not the technology. I understand the constraints, reduce complexity, and turn real needs into engineering decisions the team can execute and sustain.
I work alongside the team, from discussion through execution. I make trade-offs explicit, create the context for good decisions, and stay accountable for what reaches production.
At RWS Integration, an infrastructure platform for B2B integrations, I was responsible for modernizing the company’s legacy system.
Nx · Monorepo · AWS Lambda · OpenVPN · Networking · Legacy modernization
I joined to lead backend engineering and soon became the team’s primary technical reference, expanding my scope across engineering and product until taking on the CTO role.
Queues · AWS Lambda · Event Sourcing · Email at scale · Product · AWS SQS · AWS SNS · AWS SES · Terraform · Apache Airflow · Amazon Redshift · OpenSearch
At APOIA.se’s crowdfunding platform, I progressed from software developer to Tech Lead, combining hands-on delivery with team leadership.
AWS SQS · React · Terraform · Payments · DevOps
I worked at an online accounting startup, developing services for a platform that combined accounting and financial management.
Node.js · Laravel · Redis · NFS-e · Integrations
I worked at Zazo during its software-house phase, building PHP projects for clients including Abril Educação.
PHP · CodeIgniter · Client projects
I held scheduled tutoring sessions and assisted teachers during COTEMIG’s technical classes.
JavaScript · C# · PHP · Technical education
My first professional experience in technology, working with IT support and infrastructure.
Hardware · Maintenance · Networks · IT support
Pingback
Event Sourcing · AWS SNS · AWS SQS · AWS Lambda · PostgreSQL · Parquet · Graph workflows
Pingback needed a workflow engine that could make its marketing platform more expressive and react to changes throughout each lead’s lifecycle.
The platform needed to preserve a complete event history while evaluating graph-based workflows without coupling producers to automation logic. At scale, full replays and global searches against a single event stream also became operationally expensive.
I designed an event-driven architecture in which domain changes were published through AWS SNS, buffered by AWS SQS, and processed with AWS Lambda. A dedicated consumer evaluated each event against the workflow graph, while every event was written to a global Event Store in PostgreSQL. As the stream grew, Apache Airflow materialized aggregate and projection tables in PostgreSQL for read use cases, avoiding global scans; the high-volume event history was later organized in Parquet for more scalable replay and analysis.
The system sustained more than 50 million events per day and kept end-to-end delay around five seconds during peak load.
Independent technical project
Ghidra · Wireshark · Reverse engineering · Electron · Vite · QuickJS · Sandboxing · Network protocols
I used WYD as a constrained systems-research environment: reconstruct a proprietary protocol and explore an independent client that could be extended safely through user-written scripts.
The project required reconstructing the network protocol without depending on the original client and executing third-party scripts without granting arbitrary access to the host machine.
I reverse engineered the protocol with Ghidra and built a standalone game client with Electron and Vite. I also developed a Wireshark dissector that interpreted the already-decrypted traffic, exposing the protocol’s messages and fields for analysis and debugging. User scripts ran in an isolated QuickJS runtime that exposed only controlled APIs, reducing the attack surface of untrusted code.
Six months of continuous execution validated the stability of the protocol implementation and script-isolation model, meeting the technical goals defined for the experiment.
RWS Integration
OpenVPN · Linux network namespaces · veth · Policy routing · iptables · Docker · Amazon ECS · Amazon EC2 · Amazon S3 · AWS KMS · SSE-KMS · Egress-only networking
RWS Integration needed secure, transparent access to customers’ private networks while supporting overlapping address ranges.
The solution had to be delivered in days, under tight budget constraints, without a managed firewall appliance, while handling CIDR collisions and asymmetric routing in AWS.
I built a containerized gateway that isolated each customer tunnel in a Linux network namespace. veth pairs, NAT with iptables, and policy routing through a secondary ENI connected each OpenVPN tunnel to the VPC without leaking routes between tenants. Client profiles were provisioned from Amazon S3 using SSE-KMS with a dedicated AWS KMS key per customer. Connectivity was egress-only by design: tunnels were initiated from RWS, and routing and security controls allowed only return traffic for sessions initiated by the platform, preventing customers from initiating access to the AWS network.
A new customer connection could be provisioned from an encrypted profile and its route definitions, with isolated tunnels, health checks, and connection recovery. The gateway met the delivery window and remained stable in operation.
05 / Contact