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.

Hey, reader! Maybe you had tried go-swagger library so far. If yes, you may notice that sometimes it’s not so easy to use. And it may look a bit complicated to start using it.

In this number of small articles, I will share my experience on how to make go-swagger more friendly. Let’s start.

Handling requests in go-swagger

By default, go-swagger generates a specific handler type for each endpoint in your Swagger scheme - that is, you will get a code-generated structure with all import parameters kindly parsed for you and a number of responders for each response type (with pre-generated structures as well).

We all love unit tests because they help us to keep our software workable. And we all hate them because they don’t appear magically - someone needs to write them. And when it comes to writing, it often takes a huge amount of time to cover the simplest cases.

But I found my way to do that without pain (okay, with less pain). And I will share it with you like a simple illustrated guide.