Techwithmatheus

Website

Techwithmatheus Microservices, .NET, and AWS. Tradeoffs, failure modes, and real systems. I work for AWS but opinions are my own. Opinions are my own.

Hey there 👋

I'm Matheus Guimaraes—also known online as — a .NET and microservices specialist, international keynote speaker, and Developer Advocate at AWS. I've been building software for over 20 years, ever since my first job as a junior video game programmer back when C++ ruled the world and .NET was just a glimmer on the horizon. I was one of the early adopters of .NET (even before my first full-time job!) and it's been a passion ever since—guiding my path through roles like developer, tech lead, architect, CTO, and startup founder. Over the years, I've helped companies of all sizes modernize and scale their systems—from scrappy startups to global enterprises like Novartis, McLaren, Dewalt, PRS For Music, Coca Cola and more. I've led digital transformations, migrated legacy systems, and designed cloud-native architectures with a hands-on, people-first approach. Today, I share what I learn with developers around the world as —through talks, blogs, videos, and very geeky whiteboard sessions. I've spoken at conferences across the globe (including keynotes), and I'm passionate about helping others grow in this industry that gave me so much. Outside of tech, I'm a gamer (Final Fantasy forever), karaoke lover, swimmer, musician, and occasional actor. I believe creativity and code go hand in hand—and there's always more to explore. Let's connect, swap ideas, or just geek out over microservices (or JRPGs)! 😄

Currently, I'm a Senior Developer Advocate at AWS.

27/04/2026

Splitting a database during a migration is where things usually go wrong.

Most systems start with one shared database…
and everything depends on it.

If you try to split it in one go, you will break production.

The safer approach?
• Trace how the data is actually used in code
• Duplicate data temporarily to remove coupling
• Keep backward compatibility during the transition

It’s not about a perfect cut.
It’s about a safe, gradual separation.

13/04/2026

Feature flags aren’t just for product experiments.

They’re one of the safest ways to migrate architecture in production.

Instead of flipping everything at once, you can:
• Send 1% of traffic to the new path
• Observe behavior
• Gradually ramp up
• Instantly roll back by switching the flag off

This is how teams reduce risk when breaking apart monoliths or evolving systems.

And today, this isn’t just if/else anymore.

Tools like LaunchDarkly, Unleash, and AWS AppConfig make this a first-class capability.

One thing I’ve been thinking about more lately:

We’ve been using feature flags to control user-facing behavior…

But what happens when systems start making decisions themselves?

Architecture is evolving. Control mechanisms like this are going to matter even more.

25/03/2026

Switching to a new system is the riskiest part of any migration.

Because that’s when:
• hidden bugs show up
• edge cases break
• and rollback suddenly matters a lot

One way teams reduce that risk is parallel run.
Run the old and new systems side by side.

Sometimes even executing the same requests in both systems using shadow testing to validate behaviour in production.

In this video I break down how parallel run works and how it complements patterns like strangler fig.
Don’t just migrate. Prove it first.

23/03/2026

Don’t migrate your monolith all at once.

It sounds like the obvious move… but it’s one of the fastest ways to introduce risk, disruption, and unnecessary cost.

There’s a better way.

In this video, I break down the Strangler Fig Pattern and how it lets you modernize your system safely, one piece at a time.

If you build or evolve backend systems, this is one pattern you need to understand.

20/03/2026

Microservices are not the starting point for most systems.

But how do you know when your modular monolith is reaching its limits?

In this video I break down three practical signals that it may be time to start thinking about extracting services:

• One module forces the whole system to scale
• Your data architecture pushes you toward distributed patterns
• Team ownership keeps colliding

Microservices should be an evolution, not an ideology.

If your modular monolith starts showing these signals, it may be time to move on.

18/03/2026

Modular monoliths are great.

In fact, for many systems they are the best place to start.

But there is a turning point.

At scale, everything still ships together. That means small changes from one team can end up waiting behind unrelated work from others.

And sometimes you even get what I call wasteful scaling. One or two modules require more capacity, but because everything is packaged together you end up scaling the entire monolith.

One way to deal with this is not a full migration, but a targeted one.

Extract the modules that have very different deployment cadences or scaling requirements into microservices and leave the rest of the system as a modular monolith.

Often that hybrid approach is enough to restore autonomy and smooth out the release cadence again.

16/03/2026

Turning a ball of mud into a modular monolith doesn’t require a massive rewrite.

In many cases, you can evolve the architecture step by step.

In this video I walk through 4 repeatable steps to bring structure back into a chaotic monolith and start rebuilding proper module boundaries.

Small changes. Big architectural impact.

If you build backend systems with .NET or AWS, follow me for more content like this.

13/03/2026

Most monoliths don’t suddenly collapse into chaos.

They start clean.

But over time:
• shortcuts accumulate
• dependencies point in the wrong direction
• boundaries slowly disappear

Before you know it, fixing one tiny bug means exploring half the codebase.

That’s architectural entropy.

If you notice these signs, it may be time to start thinking about evolving your architecture toward a modular monolith or microservices.

There’s no point waiting for the ball of mud to turn into a swamp monster.

11/03/2026

Most monoliths fail for a simple reason.

They are not modular.

A modular monolith is not just "one big codebase." It is an architecture built around clear module boundaries, data ownership, and change isolation.

When those rules are followed, a modular monolith gives you the simplicity of a single deployment while keeping the system structured enough to evolve over time.

In this short video, I explain the core rules that make a modular monolith actually work.

Address

London

Website

,

Alerts

Be the first to know and let us send you an email when Techwithmatheus posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category