Esta página está em inglês. Ainda não há tradução; o URL canónico é o inglês. Abrir a página em inglês
Software architecture that stays predictable under load and bad input
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.
Deliverables
- 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.
Trabalho selecionado
- Genie Platforms — Copilotos de vendas com IA que alinham outbound, nurturing e RevOps — sem abandonar a instrumentação já existente.
- TIVA — Pesquisa por voz e texto em segundo plano, no fluxo de trabalho da equipa — não mais um ecrã de pesquisa isolado.
- Zentact — SaaS gerido para facilitador de pagamentos: tudo o que é preciso para processar pagamentos, numa plataforma simples pronta a usar.
Serviços relacionados
- Technical audit — An independent reading of the system you have — aimed at a decision, not a severity-coloured spreadsheet.
- AI integration — Put a model inside an existing workflow, with contracts and a way out — not beside the product as a chatbot.
- Legacy modernization — Move a live platform onto a current stack in stages, with data integrity, instead of a big-bang rewrite.
- Software engineering consulting — Senior engineering judgement for companies that need a principal-level partner, not a staffed agency team.
Notas relacionadas
Perguntas que me fazem
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.