Software engineer with 15+ years of experience in the .NET ecosystem, working across software development, architecture and enterprise systems.
Throughout my career, I've worked on software in different domains and organizational contexts, building and evolving backend systems, APIs, integrations and distributed applications.
Today, my work and research increasingly sit at the intersection of:
Software Architecture · Distributed Systems · AI Engineering · Observability · Resilience Engineering
I'm particularly interested in understanding how complex software systems behave under failure, uncertainty and change — and how architecture can make those systems more observable, resilient and evolvable.
Software Engineering
│
├── Software Architecture
│ ├── Clean Architecture
│ ├── Domain-Driven Design
│ ├── Distributed Systems
│ └── Event-Driven Architecture
│
├── AI Engineering
│ ├── LLM Applications
│ ├── Retrieval-Augmented Generation
│ ├── AI Agents
│ └── Applied Machine Learning
│
├── Platform Engineering
│ ├── Containers
│ ├── Kubernetes
│ ├── CI/CD
│ └── Cloud-Native Systems
│
└── Resilience Engineering
├── Observability
├── Failure Modes
├── Technical Fragility
└── Antifragile Software
Technology changes; engineering fundamentals last longer. Right now that includes postgraduate studies in Software Engineering at PUC-Rio.
Complex systems fail in complex ways.
After years building software, I've become increasingly interested not only in how systems are built, but in how they behave when assumptions stop being true.
What happens when:
- a dependency becomes unavailable?
- traffic suddenly increases?
- a deployment partially fails?
- messages arrive late, duplicated or out of order?
- an external API changes?
- infrastructure becomes degraded?
- yesterday's architectural assumptions no longer hold?
This leads to an engineering question that increasingly influences my work:
Where is the system fragile?
Technical debt tells us something about the state of the code.
Technical fragility tells us something about the risk accumulated by the system.
I believe good architecture should help software absorb change, expose weaknesses, recover from failure and evolve safely.
C# · .NET · ASP.NET Core · Python · SQL
Clean Architecture · DDD · CQRS · Event-Driven Architecture · Distributed Systems · REST APIs
LLMs · RAG · AI Agents · Embeddings · Vector Search · Prompt Engineering · Machine Learning
PostgreSQL · SQL Server · SQLite · MongoDB · RabbitMQ
Docker · Kubernetes · GitHub Actions · Azure DevOps
OpenTelemetry · Distributed Tracing · Structured Logging · Metrics · Health Checks
TypeScript · React · Solidity · Blockchain
I use personal projects as engineering laboratories.
Rather than building projects only to demonstrate frameworks, I use them to investigate engineering questions involving:
- software architecture
- distributed systems
- machine learning
- AI engineering
- observability
- reliability
- failure modes
- quantitative experimentation
- technical fragility
Each investigation follows the same structure — question, hypothesis, experiment, evidence, conclusion — and lives in engineering-lab.
One area I'm particularly interested in is the application of resilience and antifragility principles to software engineering.
Traditional engineering frequently asks:
How do we prevent this system from failing?
I'm interested in extending that question:
How do we design systems that expose fragility early, learn from stress and become easier to evolve?
That involves exploring concepts such as:
Observability · Failure Isolation · Graceful Degradation · Fault Tolerance · Controlled Experiments · Technical Fragility · Evolution under Uncertainty
Architecture > Frameworks
Observability > Guessing
Evidence > Assumptions
Experiments > Opinions
Automation > Repetition
Resilience > Optimism
Simplicity > Accidental Complexity
Evolution > Premature Perfection
I'm always interested in exchanging ideas about:
Software Architecture · Distributed Systems · .NET · AI Engineering · Observability · Resilience
Especially when the conversation starts with:
"What happens when this assumption fails?"
Reach out on LinkedIn.