ENGINEERINGTHINKING & PRACTICE

The technical decisions behind the systems I build.

A collection of engineering topics shaped by my experience with backend systems, distributed processing, performance, data, and software evolution.

01PROBLEM SOLVING

I try to understand the problem before deciding how to solve it.

A requirement describes what needs to change, but it does not always explain why the problem exists. I try to understand the underlying behavior and constraints before choosing an implementation.

Understand

What is the system trying to achieve? What is happening today? What constraints already exist?

Investigate

I trace the behavior through the relevant code, data, and interactions to identify where the actual problem is.

Evaluate

When there are multiple possible solutions, I consider their trade-offs instead of assuming the first approach is the right one.

Validate

I verify that the change solves the original problem and behaves correctly within the rest of the system.

02ARCHITECTURE

Architecture should serve the system, not the other way around.

I don't see architecture as a fixed template. The right structure depends on the system's responsibilities, constraints, expected growth, and the kind of changes it will need to support.

Understand the boundaries

Before defining services or layers, I try to understand what responsibilities belong together and where clear boundaries between concerns should exist.

Choose the right level of complexity

Not every problem needs distributed services or additional infrastructure. I prefer introducing complexity when it solves a concrete system requirement.

Design for change

Systems evolve. I try to isolate responsibilities and changes so that extending one part of the system does not unnecessarily affect everything around it.

03PERFORMANCE

Performance starts with understanding where the system actually spends its resources.

I prefer measuring before optimizing. Processing time, database workload, memory usage, allocations, and expensive operations can reveal very different bottlenecks, even when the system appears slow from the outside.

Measure before changing

I try to identify the actual cost of an operation before deciding that it needs optimization. Without measurement, optimization can easily become guesswork.

Remove unnecessary work

Sometimes the best optimization is avoiding an operation entirely: an unnecessary database query, repeated calculation, transformation, allocation, or state lookup.

Understand the cost of abstractions

Abstractions can improve maintainability, but they also have runtime and memory implications. I consider those trade-offs when working on performance-sensitive paths.

Validate under realistic load

A change that looks better in isolation may behave differently under real workload. I use high-volume and stress scenarios to compare behavior before and after an optimization.

PERFORMANCE PRINCIPLEThe fastest operation is often the one the system does not need to perform.

04SCALABILITY

Scaling is about controlling how a system behaves as the workload grows.

When workload increases, simply adding more resources is not always enough. I think about where work accumulates, how components interact, and which parts of the system need to scale independently.

Find where work accumulates

Increasing traffic can expose bottlenecks in unexpected places. I look at processing stages, queues, database operations, and shared resources to understand where pressure is building.

Control concurrency

More parallel work does not automatically mean more throughput. Concurrency needs to be controlled according to the capacity of the system and the resources it depends on.

Separate independent workloads

When different workloads have different characteristics, isolating them can prevent one type of work from affecting the processing capacity of another.

Design around real constraints

Scaling decisions should consider CPU, memory, storage, network, database capacity, latency, and operational complexity rather than focusing on a single metric.

SCALABILITY PRINCIPLEMore concurrency is not always more throughput.

05DATA

Data design is part of system design.

The way data is stored, accessed, and synchronized affects the behavior of the entire backend. I consider the purpose of the data, its access patterns, consistency requirements, and the workload the system needs to support.

Model for the problem

Data models should represent the domain and the relationships that matter to the system. I start from how the data is used rather than designing tables in isolation.

Understand access patterns

The same data can require different structures depending on how frequently it is read, written, filtered, aggregated, or shared across different parts of the system.

Choose storage deliberately

Relational and non-relational storage solve different problems. I consider the characteristics of the workload before deciding where and how information should be persisted.

Keep state intentional

Cached or temporary state can improve performance, but it also introduces consistency and lifecycle concerns. I try to make those responsibilities explicit.

06EVOLUTION

Good engineering also means knowing how to change an existing system.

Software rarely stays in the state it was originally designed for. Requirements change, workloads grow, assumptions become outdated, and new constraints appear. I see evolution as part of the engineering process rather than something that happens after development.

Understand what already exists

Before changing an existing system, I try to understand its current behavior, dependencies, data, and the reasons behind important constraints.

Change incrementally

Large changes can increase risk. When possible, I prefer separating changes into smaller steps that can be understood, tested, and validated independently.

Preserve what still works

Not everything in an existing system needs to be replaced. I try to distinguish between what needs to change and what can continue serving its purpose.

Make future changes easier

A successful change should ideally leave the system in a state where the next change is easier to understand and implement, rather than adding another layer of accidental complexity.

EVOLUTION PRINCIPLEA system should become easier to change, not harder, as we understand it better.

07TECHNICAL DECISIONS

Every technical decision exists within a context.

I try to evaluate solutions based on the problem they need to solve, the constraints of the system, and the consequences they introduce. There is rarely a universally correct technical choice.

01Problem

What are we actually trying to solve?

02Constraints

What limitations already exist?

03Trade-offs

What do we gain and what do we give up?

04Consequence

How will this decision affect the system later?

DECISION PRINCIPLEThe best technical decision is the one that makes sense for the problem and the context.