Systems

There is a moment, when you open a system, when you are no longer looking at code, nor servers, nor APIs, nor diagrams that pretend calm. You are looking at an animal. It breathes. Sometimes it coughs. Sometimes it growls. Sometimes it pretends to sleep and then, at the first spike in traffic, it stands up like a frightened horse and kicks at everything around it.

Most people, in front of that animal, divide into two tribes: the tamers with the whip, and the poets who photograph it from afar. I have always thought that another figure is needed: someone who goes down into the engine room without romanticism and without violence. Someone who learns to distinguish, amid the noise, the clean sound of things that are working.

Complex systems do not fail because they are large. They fail because they become opaque. When you no longer know where the air is flowing, when the heat has no escape routes, when a component breaks and you only discover it because everything else starts to tremble. Opacity is the most common and underestimated disease. It doesn’t make noise right away. It lets you work. It even lets you deliver. Then, one day, it presents you with the bill with interest: bugs that do not repeat, incidents that seem like ghosts, performance that collapses like a hastily assembled stage. And there you are, looking for blame in a file, when the blame is in the invisible shape you have given to things.

I have a simple vision, and for this reason difficult: a system must be understandable. Not “because it is beautiful,” not “because it is elegant,” but because it is the only way it can last without devouring the people who maintain it. An incomprehensible system is a system that demands human sacrifices. Even if it doesn’t admit it. Even if the dashboard is green.

The word “architecture” has been ruined by those who pronounce it as if it were a crown. For me, it is not a title, it is a gesture. It is deciding where to let the weight pass. It is choosing which things should be close and which should be far away. It is accepting that every shortcut is a signature on the wall: “here we chose not to understand.” Sometimes that signature is necessary. But it must be placed with awareness, like marking a map before crossing a desert.

I come from a time when technology was poorer and, for that reason, more honest. When programming meant feeling the limit as one feels the edge of a table in the dark. I learned early on that the limit is not an enemy. It is a strict teacher. The limit forces you to choose. And choosing is the noblest part of this profession.

Then came modern times, with their infinite promise: cloud, microservices, tools that do everything, frameworks that caress your forehead and say “don’t worry.” And instead, you need to worry, but in the right way: not with paranoia, but with attention. Because when everything is easy, the risk is that nothing is understood. And when nothing is understood, everything breaks together.

My obsession, if you want to call it that, is readability. A system must be readable, like reading a city. Not to know every brick, but to know where you are, where you are going, where the exits are, where the squares are, where the dead ends are. A readable city does not prevent you from getting lost, but allows you to find yourself again. A readable system does the same thing: it allows for mistakes without turning them into catastrophe.

And here comes into play something that many call “culture,” as if it were a poster in the office. I call it responsibility. Because architecture is not just technical: it is operational ethics. It is deciding whether the people who come after you will find a ship with clear tools or a hold full of closed boxes without labels. It is choosing whether those on call will experience manageable nights or nights of superstition.

I am convinced that the difference between a good system and a bad one is measured in an almost invisible detail: the time it takes to understand “what is happening” when something happens. Not when everything is normal. When something is wrong. That time is the real capital. If it is short, the system respects you. If it is long, the system is already consuming you.

When we talk about AI today, we always hear the same noise. There are those who sell it as magic and those who fear it like a ghost. I see it as a new kind of tool: powerful, ambivalent, capable of amplifying anything. If you have an opaque system, AI makes it more opaque, because it gives you answers that seem like truths but are just well-dressed probabilities. If you have a comprehensible system, AI becomes a multiplier: it helps you explore, automate, and understand before the damage arrives.

For me, AI is not the end of architecture. It is the beginning of a more demanding architecture. Because it introduces a component that is not deterministic. A component that “thinks” without explaining. And so the question is not “how intelligent is it,” but “how do I keep it within a human system.” How do I put it in good, non-punitive cages: observability, logging, prompt versioning, evaluations, regression datasets, fallback. The discipline required is no different from that needed for anything complex. Only now the mistake can be more creative. And thus more dangerous.

I love systems that know how to fail. Not those that promise immortality. Those that, when the unexpected arrives, do not collapse the world, but bend with dignity. This requires a word that often disappears from pitches: margin. Margin of time, margin of resources, margin of attention. A system without margin is a system that lives in apnea. Sooner or later it faints.

There is one thing I carry with me from cinema, and that seems distant but is not: editing. A film works when you know what to show and what not to show. A system works the same way: what you expose, what you hide, what you make simple, what you leave complex but confined. Architecture, after all, is the editing of responsibility. You cut the superfluous, connect distant scenes with a clean transition, imply without explaining everything, but ensure that the viewer does not get lost.

And then there are chess, which are not a decorative passion, they are a grammar. In chess, you learn that the mistake is not an accident, it is a consequence. That every move creates possibilities and debts. That haste is almost always an elegant way to lose. That position often matters more than momentary tactics. This, in systems, is identical. A shortcut may seem like a brilliant combination, but if it leaves you with the king in the center and the lines open, sooner or later someone will enter. And they won’t ask for permission.

The vision, if I have to express it with an image, is this: to build systems like fleets. Not like castles. The castle is a promise of invulnerability, and to keep it you must close yourself off. The fleet, on the other hand, exists to move. It knows it will change course. It knows it will encounter storms. It knows it will lose pieces. But it is designed to continue. It is made of ships that can replace each other, of clear signals, of simple procedures when the sea turns rough. A fleet is not perfect. It is resilient.

And I, when I work, always think of those who will come after. Not out of nostalgia, but out of respect. Because the true greatness of a system does not lie in the day you launch it. It lies in the thousand days after. It lies in the hands that touch it when you are already elsewhere. It lies in the ability to welcome new ideas without becoming a monster. It lies in elasticity, readability, margin. It lies in that rare quality: being reliable without being rigid.

Here, under this tag, you will find notes. Some are technical, with names and numbers. Others are almost stories, because I cannot entirely separate the machine from the story that the machine makes possible. You will find principles, choices, compromises, small betrayals, and great recoveries. You will also find doubts, because the best systems arise from people who do not need to pretend certainties.

If you have made it this far, perhaps you also have the feeling that a system is not “software.” It is a pact. Between people and time. Between intention and reality. Between what you imagine and what happens when no one is watching you.

And so, welcome to the engine room. Here, nothing is celebrated. We listen. We measure. We correct. We restart. And, when it goes well, you hear that rare, almost musical sound: a system that holds up, and does not ask for sacrifices. Only attention. Only care. Only a bit of human, stubborn clarity.