What is software engineering? A mixture of science and craftsmanship, built on rules and logic. Once done, we expect a program to run the same predictable way, over and over again.

Applications therefore are deterministic: the same input leads to the same output (if we treat state and side effects as input). But we still somehow have bugs, not because the app magically changes its behavior, but because programs are complex, and because we are humans.

As a platform architect, I often discuss Infrastructure as Code (IaC) with my clients. This simple shift in IT infrastructure management, which has been widely adopted by the modern tech industry, has many implicit benefits. In this article, I will explain what adopting IaC means for businesses and how it can help reduce costs and increase profits for the whole organisation, whether technical or non-technical.

Today’s world is very different from what it was 20 years ago. We are used to a website loading in a second, a mobile app calculating a complex route in moments, or ordering a taxi with one button. This is made possible by combining many technologies and approaches that ensure smooth and fast operation.

It is hard to imagine a taxi service suddenly stopping for 10 minutes. It is equally hard to picture a map or GPS navigator that suddenly stops updating, or a major online store freezing during payment.

In software engineering, the term happy path refers to the ideal scenario where everything works as planned. It’s natural to begin system design by focusing on these positive scenarios - they’re simple, straightforward, and align with how most people envision their product functioning.

However, stopping at the happy path is a mistake. While it’s often sufficient for stakeholders from business backgrounds who lack technical expertise, it fails to address the majority of a system’s complexity. Robust systems excel not in perfect conditions but in their ability to handle problems and recover from failures.

In this article, I will give you a no-brainer for choosing the right architecture for any project. Right doesn’t mean perfect, but it does mean good enough.

Virtual machines (VMs) are the basic building block of cloud infrastructure - all cloud products like databases, orchestrators, message queues, functions and others are based on them. Many companies also use virtual machines as the foundation of their cloud landscape, running all sorts of services and applications on them.

In this article, I will explain ways and approaches for scaling VMs.

Logging is an integral part of any application. However, the correct location and use of the logger in the project structure raises questions even for experienced developers.

There are several ways of doing this, of which I give preference to one. I will explain why.

In this article, you will learn what application scaling is, and how cloud infrastructure simplifies the process and makes it more useful for business.

How to implement transaction management in a hexagonal microservice? How to keep the isolation of the application layer and the database adapter? In this article I will share my experience in solving this problem.

This is the first article in a series dedicated to FSM usage in distributed system architecture. We will talk about domains, transactions, and sagas. But let’s start with the basics.

Finite-State Machine

When we think about the finite-state machine, we probably imagine some computer science-related entities, math, and diagrams like that:

Besides scientific language, a finite-state machine is a final set of states and the transitions between them. When it comes to real engineering, states are a set of consistent states in which the model can be. Normally the set is not huge - having an FSM of a hundred states will cause really complex code. In my experience, it is something between three for the simplest models and 20-30 for most complex ones.