Kolomiiets Technical Inform

Reliability is a foundational pillar when building resilient systems, especially for critical components. Outages and malfunctions pose serious risks to any workload, so a truly reliable system must be designed to detect, withstand, and recover from failures within an acceptable timeframe. It must ensure continued functionality and maintain availability so that users can access services as expected, both in terms of uptime and quality. 🔧 Aligned with Azure’s Reliability Checklist Keep it simple and efficient Strive for a solution that meets requirements without unnecessary complexity—simplicity simplifies reliability Identify and prioritize flows Map out user and system flows, assess their criticality, and focus engineering efforts on those with the highest business impact Conduct failure mode analysis (FMA) Investigate every dependency and component with a methodical FMA to uncover weak points, and design mitigation strategies accordingly Define clear reliability and r...

Have you ever seen a fully implemented, truly and absolutely by-the-books REST API? With all the correct HTTP methods, status codes, and the perfect design? No? Me neither. And you might ask — why not? After all, it's supposed to be easy , right? Well, yes — technically, it is easy. But in real life, you always run into edge cases. Let’s take a simple example. According to REST principles, if you want to retrieve data, you should use the GET method. Simple and elegant, and documented everywhere. But then the question arises: how do you pass parameters in a GET request? Answer: via URL path or query parameters. But as you already know, there’s a limit to how much you can fit into a URL — usually around 2048 characters . That’s fine for small, basic queries. But what about advanced searches ? You want to pass dozens of filters , custom ordering , maybe even a list of IDs to fetch. Sometimes it’s a list of GUIDs — and not just one or two, but hundreds . In these cases, G...

Small and medium-sized businesses often face a common challenge: the absence of experienced cloud engineers. Due to limited resources, teams typically choose the quickest path—getting things done in the easiest, fastest way. Unfortunately, this approach often leads to solutions that aren't secure, cost too much, and become nearly impossible to extend or manage effectively. Recognizing this critical challenge, Microsoft Azure has developed the Well-Architected Framework. This comprehensive set of guidelines and best practices helps businesses assess their existing solutions and guides them toward building robust, secure, cost-effective, and manageable cloud infrastructures from the start. The Azure Well-Architected Framework is structured around five essential pillars: Cost Optimization : Ensuring that cloud resources are used efficiently and effectively, reducing unnecessary expenses. Operational Excellence : Focusing on the ability to run and monitor systems effectively, ensuring ...

I keep hearing, “You MUST start with a monolith.” Every new project? Always? When I hear that, two thoughts immediately come to mind:      1️⃣ “It depends.” You can’t just blindly say every project must start as a monolith.      2️⃣ My inner Dushnylo whispers: “Time to make a post about this.” So, here’s my take: I disagree. Not only do I disagree, but I believe the most critical and dangerous part of system design is analyzing and understanding business needs before making architectural decisions. Why? Simple. Imagine you’re building a streaming platform that processes massive amounts of data, handles notifications, and integrates with third-party services. Does this sound like something you’d build as a pure monolith? Of course not. But I do agree on one thing—you have to start somewhere. That starting point could be a simple core application —yes, it might look like a monolith at first. But you’re not designing the entire system as a monolith. ...

Introduce My next post is about tools for managing roles and dynamically controlling access to resources. Some business requirements demand extreme flexibility, often requiring a combination of RBAC + ABAC at the same time. From my experience, I’ve seen a lot of solutions, but most don’t cover all the key points. There are three circles that are really hard to combine: Performance, Security, and Flexibility . And when someone tries to implement all three—oh, it’s painful. But I found a technology that (almost) solves this challenge: Cerbos —a scalable, open-source authorization layer for handling roles and permissions. ( Cerbos site ) Why is it good? ✅ Centralized configuration – Everything is managed in one place. ✅ Easy integration – SDKs are available for all popular languages:     🔹 .NET, Go, Java, JS, PHP, Python, Ruby, Rust ✅ Great documentation – Clear examples and guidance. ✅ Playground for testing – No need to run an app or set up tools. Just te...

  Exploring RavenDB: First Impressions and Key Features 🚀 At the recent conference ( https://devworldconference.com ), I was impressed by the possibilities and feature set of RavenDB. It’s not just another NoSQL database—it delivers on its promises with ease of use, powerful features, and high performance. In this post, I’ll share my first-hand experience with RavenDB, highlighting its key features, what makes it stand out, and my thoughts after testing it in a real-world pet project. Let’s dive in! 👇 List of features: Database Management Studio & Open-Source NoSQL Document Database – Ease of Use It's not just a slogan—it’s true. It took me around 5 minutes to run RavenDB and its Database Management Studio on my laptop. You can start experimenting with this DB locally in just a few minutes, without digging through tons of tutorials or manuals. No need to install dozens of tools and subsystems—just a few minutes, and you have a full sandbox for exploring and learning everyt...

Lately, I've noticed a recurring and perplexing theme in numerous posts and articles. Certain tech authorities assert that some established patterns are superfluous. For instance: "The repository pattern is unnecessary; simply use the ORM directly within your business logic—no need for abstractions." Therefore, I've chosen to initiate a new series titled “Dushnylo” (Definition: An individual who is excessively critical, focuses on minute details, and overwhelms others with arguments about why something is incorrect or flawed.) The inaugural topic in the “Dushnylo” series: "Reduced Abstraction, Increased Direct ORM Usage in Business Logic" Why circumventing abstractions breeds disorder: Strong Coupling and Reduced Testability By directly integrating an ORM into your business logic, you create a strong dependency between your business layer and the database implementation. This strategy: Makes migrating to a different ORM or database significantly more chal...