Software architecture that stays predictable under load and bad input

For CTOs facing a rewrite, a service split or a model next to CRUD.

System design for live products: what should exist, where the boundaries sit, and how the system fails.

You leave with

A design the team can build

A written review: current shape, constraint, options, recommendation, and what we are explicitly not doing.
C4-style or equivalent diagrams only where they change a decision.
Interface sketches (types, events, API shapes) the team can implement.
Optional implementation of the first boundary in the codebase.

See it done

IMF · Sitecore 9.2 to XM CloudHeadless Next.js front over GraphQL Genie Platforms · AI SDRConversational AI running as production services Mindshine · TIVAVoice and text retrieval across any data source

See more details

I help companies design and review software architecture for products that have to keep running. The work is not a framework catalogue. It is the set of boundaries, contracts, and operational paths that stay predictable under load, invalid input, and provider failure. I am typically asked in when a SaaS is about to scale, when a rewrite is being debated, when AI is about to enter a deterministic system, or when the current shape of the software is slowing every change. You get a senior architect who still implements: the review is useless if it cannot survive contact with the repository and the traffic.

Who this is for

CTOs and founding engineers who need a second senior mind on a scaling product.
Teams about to commit to a rewrite, a microservice split, or an event backbone.
Companies placing an LLM next to a system that is currently rules and CRUD.
Engineering leaders preparing a technical due-diligence conversation.

Problems architecture is actually for

Every feature requires a tour of four services and an oral history.
The 'modular monolith' is a monolith with extra YAML.
Latency, cost, or failure correlation appeared only after traffic got real.
A rewrite is being sold as architecture, but the constraint was never named.

What I help with

System boundaries and API contracts, including what must stay synchronous.
Data ownership, migration strategy, and how to change a live model.
Where AI, automation, and deterministic code should sit relative to each other.
Reliability: retries, idempotency, observability, and human fallback.
Architecture reviews that produce a decision, not a 60-page PDF nobody owns.

How an architecture engagement runs

I read the running system before I draw. Repositories, deploy graphs, incident notes, and the workflow the software is supposed to serve. Then a short set of options with trade-offs – not a single 'target architecture' that ignores the team size. If we proceed to implementation, the first merge is a slice that proves the boundary, not a platform scaffold.

What I evaluate in an architecture review

A useful review is a series of questions you can fail. These are the ones I start with.

Constraint

Which metric or failure is actually expensive – lead time, incident rate, cost, correctness, or a date? Architecture that does not name this is taste.

Change shape

Where do changes concentrate? If every request touches the same module, splitting services will not help until that module is decomposed.

Contracts

Are boundaries typed and versioned, or are they 'we will be careful'? AI outputs need contracts more than human-written JSON does.

Failure

What happens when the provider, the queue, or the model is wrong? If the answer is 'the user retries', you do not have a design.

Operability

Can a new engineer find the path from HTTP to data in an afternoon? If not, the diagram is lying.

Team fit

An architecture that needs a platform team you do not have is a future outage. I will not recommend Kafka because it is on a slide.

Architecture anti-patterns I decline to bless

Microservices as a proxy for missing module boundaries.
Event-driven everything, including reads that needed a query.
A shared database treated as an integration layer.
Putting an LLM in the request path of a correctness-critical workflow with no validator.

Servicios relacionados

Notas relacionadas

Preguntas que me hacen

When should a startup hire a software architect?

When a decision is expensive to reverse: data model, multi-tenant boundaries, a rewrite, or putting a model in a customer-facing workflow. You do not need a full-time architect to pick a CSS library. You do need one when two quarters of work depend on a boundary that is currently implicit.

Do you produce architecture documents without writing code?

Yes, as a bounded review. I still ground the document in the repository. A review that never opens the code is a branding exercise.

Request an architecture review

The useful input is the constraint, the repo shape, and the decision you are trying not to get wrong.