Blog on sadensmol

Learning System Design #13: To RAG or not to RAG

Wed, 05 Aug 2026 00:00:00 +0000

Part #13 of the “Learning System Design” series! This time — RAG, Retrieval-Augmented Generation. The three letters everyone drops into every AI architecture diagram, usually right next to a vector database nobody in the room can quite explain the need for. I kept nodding along in those meetings until I actually sat down and built the thing — and it turns out RAG is far less mysterious, and far more of a plain old search problem, than the hype makes it sound.

Learning System Design #12: Understanding JWT

Mon, 29 Jun 2026 00:00:00 +0000

Part #12 of the “Learning System Design” series! This time it’s JWT — three Base64 strings everybody copy-pastes from a tutorial and almost nobody can explain when something goes wrong. I’ve debugged enough “Hash invalid” and “token expired but it’s not expired” incidents to think it’s worth slowing down and looking at what’s really going on.

The mental model I keep coming back to is a stamped passport. It’s self-contained, it carries claims about you, any border agent can verify it without phoning the country that issued it — and it expires. That’s a JWT.

Learning System Design #11: The Many-Factor App — Why 12 Factors Are Not Enough in 2026

Mon, 18 May 2026 00:00:00 +0000

Eleventh part of the “Learning System Design” series! This time — the 12-Factor App. Or rather, why “12” stopped being enough about a decade ago, and what a modern Go microservice actually has to do today.

I keep running into the same situation. Someone joins a team, opens the README, reads “we follow 12-factor,” and assumes the conversation is done. Then we deploy and discover the service has no idempotency keys, no circuit breakers, no SBOM, env-var secrets in kubectl describe pod, prompts hard-coded in source files, and no canary strategy. Technically 12-factor — and yet the design is fifteen years behind reality.

Learning System Design #10: End-to-End Encrypted Backup for a Personal Home Server

Thu, 23 Apr 2026 00:00:00 +0000

Tenth part of the “Learning System Design” series! This time — a really juicy one. How do you design an end-to-end encrypted backup system for a personal home server that stores your photos, videos, notes, and a zoo of embedded databases — and do it on an ARM box with 4 GB of RAM, while still letting your phone and laptop read the data without ever trusting the cloud?

Learning System Design #9: ClickHouse — Why Analytical Databases Are Absurdly Fast

Mon, 20 Apr 2026 00:00:00 +0000

Ninth part of the “Learning System Design” series! This time — ClickHouse. The columnar database that scans a billion rows in under a second on a single laptop and powers the analytics of Plausible, PostHog, SigNoz, CloudFlare Radar, and a long list of quant trading shops.

I got curious about ClickHouse when I realized every modern observability and product analytics tool I respected was built on top of it. Grafana Cloud, PostHog, Signoz, Uber’s M3 — same engine underneath. So I spent some time digging into what makes it tick, and honestly, the design is beautiful. It’s a rare case where “100× faster than Postgres” is not marketing but actual everyday experience on analytical queries.

Learning System Design #8: WebRTC — How Real-Time Communication Actually Works

Fri, 10 Apr 2026 00:00:00 +0000

Eighth part of the “Learning System Design” series! This time — WebRTC. The technology that powers every video call you’ve ever made in a browser, every screen share in Google Meet, and every peer-to-peer file transfer that “just works” without installing anything.

Before WebRTC, real-time communication on the web required Flash, Java applets, or proprietary plugins. WebRTC made it a native browser capability — no plugins, no downloads, no intermediary servers for the actual media transfer. And the best part? It’s not just for video calls.

AI: The Future We Wanted or the Trap We Didn't See?

Fri, 03 Apr 2026 00:00:00 +0000

The developer world has split in two. Open any tech forum, any Twitter thread, any Slack channel — and you’ll find the same fight. Camp one: “AI makes me 10x more productive, stop being a dinosaur.” Camp two: “AI is making developers dumb, we’re losing our craft.” Both sides are loud. Both sides have data. And both sides are missing the real point.

Learning System Design #7: Kubernetes — The Complete Guide

Tue, 24 Mar 2026 00:00:00 +0000

Seventh part of the “Learning System Design” series! This time — Kubernetes. The thing that every backend engineer eventually encounters, and the thing that makes you question your career choices when you’re debugging a CrashLoopBackOff at 3 AM.

But seriously — K8s is the industry standard for running containers in production. Whether you love it or hate it, you need to understand it. Let’s break it down.

What is Kubernetes?

Kubernetes (K8s — the “8” stands for the eight letters between “K” and “s”) is an open-source container orchestration platform. Docker lets you package your app into a container. Kubernetes manages thousands of those containers across many machines.

Learning System Design #6: AI Agents

Mon, 16 Mar 2026 00:00:00 +0000

Sixth part of the “Learning System Design” series! This time we’re talking about AI agents — the thing that took the industry by storm and turned “just ask the AI” into “let the AI do it for you.” If you’ve used Claude Code, Cursor, or GitHub Copilot agent mode — you’ve already interacted with one.

But what actually makes an agent an agent? How does it decide what to do? And most importantly — when should you build one vs just writing a normal program? Let’s figure it out.

Learning System Design #5: Understanding PostgreSQL Locks

Thu, 12 Mar 2026 00:00:00 +0000

Fifth part of the “Learning System Design” series! This time we’re going deep into PostgreSQL locks — the thing nobody thinks about until their production database grinds to a halt because someone ran an ALTER TABLE on a busy table at peak hours.

Locks are the mechanism PostgreSQL uses to coordinate concurrent access to the same data. Every SELECT, UPDATE, INSERT, DELETE, ALTER TABLE — they all take some kind of lock. Most of the time you never notice because PostgreSQL handles it automatically. But when something goes wrong — a migration blocks all traffic, a deadlock kills transactions, or an idle connection holds a lock for hours — you really need to understand how this works.

Learning System Design #4: Saga Pattern

Thu, 05 Mar 2026 00:00:00 +0000

Fourth part of the “Learning System Design” series! This time we’re tackling the Saga pattern — something you’ll inevitably run into the moment you split a monolith into microservices and realize your nice BEGIN/COMMIT doesn’t work across service boundaries anymore.

The Problem

In a monolith, distributed transactions don’t exist. You have one database, one transaction:

BEGIN TRANSACTION
 1. Deduct money from wallet
 2. Create order record
 3. Reserve inventory
COMMIT

Step 3 fails? Database rolls back everything. Done.

Learning System Design #3: Rate Limiting

Thu, 26 Feb 2026 00:00:00 +0000

Third part of the “Learning System Design” series! This time — rate limiting. Something every backend developer deals with sooner or later, and something that comes up in almost every system design interview.

The concept is dead simple — control how many requests a client can make in a given time window. But the devil is in the details. There are multiple algorithms, each with different trade-offs, and picking the wrong one can either leave your system unprotected or annoy your users with unnecessary rejections.

Learning System Design #2: Secure Game Launch for 3rd Party Integrations

Thu, 19 Feb 2026 00:00:00 +0000

Second article in the “Learning System Design” series! This time we’re tackling something very specific — how to securely launch a game when it’s integrated with 3rd party operators and aggregators.

If you’ve ever worked in iGaming or any B2B game provider setup, you know the drill — your game doesn’t live on your own website. It gets launched inside someone else’s platform, via redirect or iframe. And you need to make sure that the session is secure, can’t be hijacked, and works correctly even when things go wrong.

Learning System Design #1: How HTTP Works

Thu, 12 Feb 2026 00:00:00 +0000

This is the first article in my “Learning System Design” series where I’m going through fundamental topics every backend engineer should know well. And what better place to start than HTTP!

We use it every day, but how often do we actually think about what’s happening under the hood?

Request-Response. Simple as it is.

HTTP is a request-response protocol. Client sends a request, server returns a response. Every interaction follows this pattern — no surprises here.

Things I Hate in Go. Fourth.

Tue, 13 May 2025 00:00:00 +0000

“Simplicity, efficiency, and reliability” — the main principles in Go.

Today we are going to talk about immutability — which is hardly linked to Go’s “efficiency” and “simplicity” principles.

Immutability is not a thing in Go!

Since you have pointer methods and ability to work with pointers, you can change actually everything! Moreover it’s highly encouraged by programmers to return pointers to large structures and pass them by pointers, which leads to lack of immutability.

Go Gems: 1. Powerful Go Context in MSA

Sat, 05 Oct 2024 00:00:00 +0000

We all know Go’s context package!

https://pkg.go.dev/context

It has very useful methods, and one of them — WithTimeout. It allows us create a Context which could be cancelled automatically in certain period of time.

context.WithTimeout. Why is it useful?

Imagine you have an application with microservice-based architecture where you have a few microservices which communicate with each other:

For example “Service 1” sends some request to “Service 2” which sequentially sends request to “Service 3”. This chained requests pattern is called “Synchronous communication pattern in MSA”.

Count Your Money in Go Without Floating Problems

Tue, 12 Dec 2023 00:00:00 +0000

Money…

When we hear this at the start of development first we think about is “floating point numbers precision” and “money value representation”.

So how to deal with money, how to store and how to pass them around — those are the questions I’d like to cover in this short essay.

Why is it a problem at all?

Standard float types in Go have some certain precision (like in any other language), and you cannot use them for money operations. This simplest example here is the following:

Things I Hate in Go. Third.

Sat, 23 Sep 2023 00:00:00 +0000

“Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values.” — Go Code Review Comments.

Why every time I take some interview or do the test task — reviewers ask me about this problem?

Where do you put interfaces? No you failed our test, because you placed your interface along with your implementation. — https://github.com/sadensmol/test_faraway

Things I Hate in Go. Second.

Wed, 06 Sep 2023 00:00:00 +0000

“Each time a defer statement executes, the function value and parameters to the call are evaluated as usual and saved anew but the actual function is not invoked” - Go specification.

What does it mean? Let’s check how do we use defer.

One point to note here is that we use a function invocation here but the actual call is delayed until defer is get to its turn.

Things I Hate in Go. First.

Thu, 06 Jul 2023 00:00:00 +0000

“Accept an interface, return a struct” — well known Go idiom.

Let’s look more in deep into it. First, what comes on my mind when I think about this idiom is SOLID.

We are following Dependency Inversion principle here by injecting dependencies through the help of Go interfaces. Here we are using constructor injection:

type UserService struct {
	r IUserRepository
}
type IUserRepository interface {
	GetByID(ID string) (*User, error)
}
func NewUserService(r IUserRepository) (*UserService, error) {...}

We could pass any user repository here and dynamically switch the service behaviour which provides us with all the benefits of DIP - loose coupling, modularity, testability etc…

My Clean Architecture Go Application

Thu, 09 Mar 2023 00:00:00 +0000

I fully moved to Go stack a few months ago and suffered a lot with the good approach for architecturing the code and structuring the project. Went through multiple open source projects, talked to multiple Go devs and finally came up with some template and approaches I’m using for all new projects. Maybe this will be interesting to all who are struggling with the same problems!

I will go through creation simple account management API and try to apply my vision of clean architecture in Go applications.

From Java/Kotlin to Go(Golang)

Tue, 28 Feb 2023 00:00:00 +0000

About myself

I started as a Java developer about 10 years ago with Java 5. It was time when most enterprises were built on Java EE and running on Jboss. EJB, XLS, Struts, Hibernate, Eclipse and similar technologies were using at that time. Applications were heavy, too resource hungry and used dedicated servers. At that time I was mostly developing CLI tools, then switched to Spring and video processing (Red5, Wowza) where Flash was mostly used for web and client side applications.

Rate Limiting in Multi-Tier Apps

Tue, 24 Jan 2023 00:00:00 +0000

One day we found that we need to rate limit some of our not secured API endpoints. Mostly they are related to the functionality like password reset or sending feedback/contact me forms. In this application we don’t use authentification for these endpoints and they are actually publicly exposed.

Here is a structure of our web application.

We have a Front-End (FE), Back End for Front End (BFF) and Back End. FE is a react.js application, BFF is next.js based and our BE are written in Go.

Exception Based Flow Control in Spring Boot Application

Sun, 18 Sep 2022 00:00:00 +0000

Here I’d like to describe the way I’m using while working on different Java/Kotlin/Spring Boot microservice based applications. The code for demo the idea is located here:

https://github.com/sadensmol/article_sb_exceptions

Why exception based?

You ask “Why exception based?”, and it’s a good question! All modern languages have special structures to control the execution flow — the most known one is if statement

if (expression is true) then
 {execute block a}
else
 {execute block b}

Here we check the expression and decide what code to execute based on the evaluation result. But we mostly choose between 2 cases - positive case (forward evaluation) - when the expression suits our expectation and fallback case - when we should handle something unwanted or unexpected. Doesn’t the second sound like exception case? It does!