C. RODRIGUES

Background

Why I write the doc first

A design nobody can argue with is a design nobody has read. This is how I work, and the parts of the job I am deliberately not good at.

{{TITLE}} {{YEARS}} years · {{COMPANY_COUNT}} organisations {{LOCATION}} · {{WORK_MODE}}

What I do

I build the part that has to keep working.

{{YEARS}} years of backend and distributed systems, most of it on the services other teams are forced to depend on: the ledger, the order pipeline, the ingestion path, the thing that pages at 3am. Lately more of that time goes into deciding what should be built at all, which is the part I want more of.

The move into architecture has not meant leaving the code. A design I cannot implement myself is a design I do not understand yet, so I still take the first vertical slice through anything new. The diagram comes out of the code as often as the other way round.

Architecture diagram of a system I designed
Now
{{CURRENT_ROLE}}
At
{{CURRENT_COMPANY}}
Domains
{{DOMAINS}}
Stack
{{LANGUAGES}}
Based
{{LOCATION}}
One system, and the shape it settled into. Most of the work was deciding which boundaries were real.

How I work

01

The doc before the diagram

Options, trade-offs and the ones I rejected, written down where the team can disagree with them. A diagram shows what was decided; only prose explains why, and why is the part people need in two years.

02

Slices, not big bangs

Every migration ships as a sequence of reversible steps that each run in production. If a plan has a step that cannot be rolled back, that step is the plan, and it needs rewriting.

03

Boring on purpose

Postgres until it hurts, one queue rather than three, and the framework the team already knows. Novelty is a budget, and I would rather spend it on the domain than on the infrastructure.

04

On call for what I ship

Designing a system I never have to operate makes me a worse engineer. I take the pager for what I build until it is quiet, and the parts that wake me up are the ones that get fixed properly.

Design docs, event-driven, zero-downtime cutover, observability, mentoring, on call.

Limits

Things I am not.

I am not a front-end engineer. I can hold a conversation about a component tree and I will not design your interface. On a team with real product designers this has never been a problem; on a team without them, hire for it before you hire me.

I am also not an engineering manager, and I have turned the role down twice. Line management is a full job done badly by anyone still holding an architecture. If you need someone to own headcount and performance reviews, that is a different hire.