Software engineering · Full-stack systems & applied AISão Carlos, Brazil · BRT

FULL-STACK SOFTWARE ENGINEER

I help teams make difficult software systems clearer, safer, and ready to evolve.

From product interfaces to distributed services, I turn technical complexity into reliable systems that teams can understand and move forward.

Discuss a challenge
2 yr 8 mo at iFood · M.Sc. candidate in Computer Science at USP

00 / Engineering approach

Engineering for clear technical decisions.

I connect product context, system design, and implementation to move complex software forward with clear trade-offs.

01Full-stack product engineering and system design01—04

modeDay ──▶ Instrument

Follow the signal.

entering the systems

01 / Selected systems

Real problems, technical decisions, and production outcomes.

Four systems I helped move from technical direction to production.

Some details are intentionally generalized to protect product confidentiality.
01Pix key lifecycleFintech · Distributed systems

The asynchronous lifecycle of Pix keys

01 / Problem

Ownership claims, provider webhooks, and local records had to remain coherent across an asynchronous journey with multiple failure modes.

02 / Direction

Treat consistency as an explicit lifecycle, with idempotency and reconciliation instead of relying on the illusion of one synchronous request.

03 / System

Event-driven state transitions, idempotent consumers, and recovery paths aligned local and external state while keeping each step observable.

04 / Scope

Led the backend work from architectural design and data modeling through integrations, infrastructure, rollout, and production observability.

GoKotlinCQRSPostgreSQLSQSKubernetes
01 / LIVE SYSTEM MAP
02Shared capabilityPlatform engineering

Audit as a shared capability

01 / Problem

Audit records were essential, but repeated service-level implementations multiplied code, inconsistencies, and maintenance cost.

02 / Direction

Create and maintain the team’s first shared library so services could adopt one contract without rebuilding the same capability.

03 / System

A common audit contract and reusable capture layer separated the shared rules from each product flow while preserving observability.

04 / Scope

Created and maintained the team’s first shared library, reducing duplicated implementation and making a common contract easier for services to adopt.

GoKafkaDDDObservability
02 / LIVE SYSTEM MAP
03Controlled changeLegacy modernization · Integration

Modernizing without moving the risk

01 / Problem

Legacy flows carried production knowledge and business risk that could not simply be moved into a new service all at once.

02 / Direction

Separate responsibilities and migrate gradually, making compatibility, observability, and recovery part of the modernization plan.

03 / System

API- and event-based boundaries reduced coupling while parallel paths and operational signals supported a controlled transition.

04 / Scope

Worked directly on evolving legacy flows while keeping gradual migration, observability, and recovery as explicit parts of the change.

APIsEventsMigrationObservabilityRecovery
03 / LIVE SYSTEM MAP
04AI-assisted decommissioningDeveloper tooling · Applied AI

Turning service decommissioning into a guided system

01 / Problem

Decommissioning a service was a long and delicate process spread across manual checks and multiple internal systems, making dependencies, risks, and required steps difficult to see.

02 / Direction

Replace the fragmented checklist with an AI-assisted workflow that gathers context before proposing action while keeping engineers in control of the final decisions.

03 / System

Model Context Protocol (MCP) servers connected the tool to internal platforms, aggregating service ownership, dependencies, runtime signals, and operational context into a unified view.

04 / Scope

Developed the internal tool and guided flow that turns cross-system discovery into an actionable decommissioning plan that is easier to understand and execute.

Artificial IntelligenceModel Context Protocol (MCP)MCP serversDeveloper toolingWorkflow automationService decommissioning
04 / LIVE SYSTEM MAP

Technical writing

Spring Boot · Clean Architecture · Trade-offs  ·  Spring Boot · Clean Architecture · Trade-offs  ·  Spring Boot · Clean Architecture · Trade-offs

Is Clean Architecture always a good idea?

A practical argument about boundaries, abstractions and the moment architectural discipline becomes accidental complexity.

Read on Medium

02 / Research & technical authority

Research that sharpens how I design production systems.

At USP, I study how microservices can detect attacks, adapt, and recover with less human intervention.

It turns observability, feedback loops, and recovery into practical design tools.
Architecture paper accepted at AISecDev 2026Experiment in progress
Entrance to the EESC-USP campus in São Carlos, where Vinícius develops his master's research
EESC-USP · São Carlos · Personal archive
MAPE↻KNOWLEDGE

modeInstrument ──▶ Day

Back to the person.

leaving the systems

03 / Trajectory

From research to production—and back to research.

My work began in research software at UFSCar, then moved into financial products and distributed systems at iFood.

Today, production engineering and my M.Sc. research at USP shape the same pursuit: software that stays reliable as complexity grows.

span
202120222023202420252026now2027
duration
UFSCarComputer Science
4 yr 4 mo

Algorithms, systems thinking and a durable appetite for difficult questions. Jan 2021 — Apr 2025

UFSCarScientific Researcher
1 yr 1 mo

Web architecture for mental-health and substance-use rehabilitation research — Next.js, TypeScript, CI/CD. Mar 2022 — Mar 2023

FAPESPScientific Researcher
1 yr 1 mo

The same rehabilitation platform under FAPESP funding: system architecture, best practices and CI/CD provisioning. Mar 2023 — Mar 2024

iFoodSoftware Engineer Intern
9 mo

Back-office for iFood Pago, the team's first shared library, and an AI-integrated backend built at the internal hackathon. Mar 2024 — Nov 2024

iFoodSoftware Engineer
2 yr · 2 yr 8 mo at iFood

Financial products, full-stack engineering, distributed systems, production reliability, and AI-assisted internal tooling across Pix, transfers, and banking journeys. Nov 2024 — present

USPM.Sc. Computer Science
1 yr 5 mo

Self-adaptive security for microservices and the question of how software can defend itself. Mar 2025 — present

Indent = nested inside the span above · overlap is concurrency, not sequenceDashed tail = projected to Mar 2027