Why a simple feature grows once it reaches the backend

One of the most dangerous sentences in backend work is “let's just add an endpoint for that”. On screen it really may be a single button. The question changes as soon as you think about what happens after someone presses it.

I have been through this more than once. At first the task looks tiny: take the data, write it to the database, return a response. Then it turns out the same data is used by another service, that in some cases the previous record must not be modified, that nobody knows what happens if the transaction stops halfway, and that the same request arriving twice can make the system do the work twice.

Writing the endpoint is the easy part

Writing a controller in Java and Spring Boot is comfortable work. The difficulty is not the code — it is understanding which rule that code is protecting in the system.

So when a feature comes in, I try not to start from the endpoint. I ask first: which state does this operation move from, and to? Which data is allowed to change? Which data must not? What happens if the same request arrives again?

If those questions have no answers, starting to write code usually just postpones the problem by a few hours.

A backend does not exist to accept requests

I see the backend as something larger than controllers and services. The backend is where the system's rules are held. The frontend can look good, but if the rule is not enforced in the backend, the system is not good.

That is also why the systems I like most are the quiet ones. The operator does not think about which button they pressed. The system knows what has to be protected behind it.