Keeping production systems healthy and reliable is a challenge. Are your services running well? During high-traffic periods, can your system handle the load without bottlenecks or failures? What about dependencies? Is everything working fine with third-party depencies or is there an outage on cloud service provider? These are everyday challenges for DevOps and SRE teams alike.

Just like messy code gives clues about deeper issues (code smells), monitoring systems can have “monitoring smells.” when something isn’t right. These are signs that your monitoring setup isn’t as good as it should be. While I won’t be diving into how to build the perfect monitoring system. This article will explain what these smells are, how to notice them, and how to fix them.

I’ve done something.

Again.

My cat is on my lap, I’m listening to music with my headset, and I’m writing a blog post about how I moved my blog to another platform. Well, not another platform, actually. I moved it to old friend GitHub again.

This time, though, I developed something simple so I can manage my blog with my own solution.

Starting From the Beginning

What was the previous platform I was using? I was using Write.as. It’s a simple platform where you can share your posts on the Fediverse. The UI is minimal, and the main goal of the CMS platform is clear: just write and share your articles.

In this article, I will discuss the Saga design pattern. First, we’ll address some technical challenges of creating ACID transactions. Then, we’ll explore the Saga design pattern and how to implement it.

Database Per Service Pattern

First, let’s talk about microservice architecture and the database per service pattern. Basically, each microservice in an application has its own dedicated database. This allows each microservice to manage its data independently, making it easier to develop, deploy, and scale each service without affecting the others. For instance, in an online store, the user service, order service, and inventory service each have their own databases. This isolation improves flexibility, as each service can choose the best database type for its needs and makes the system more resilient to failures.

At my company, we hold a weekly “Lunch and Learn” event that I really like. It lets us share our experiences and expertise. Recently, during a chat with my colleagues, I got some basic questions about dependency injection (DI). This made me think that it would be a good idea to use one of these sessions to go over DI with the team. Also, I plan to write an article about dependency injection and its best practices. In the article, I’ll explain what DI is, how to use it effectively, and what the best practices are.

In the last article, we discussed how dependency injection (DI) helps keep our app’s parts separate, making them easier to handle and test. This time, I’ll focus on an important part of DI in .NET: lifetimes.

I’ll explain the different lifetimes in .NET: Transient, Scoped, and Singleton, and how to pick and use them for your app.

Understanding DI Lifetime Scopes

Dependency injection (DI) lifetime scope refers to how long a dependency is used and stored in an application. Managing these lifetimes is important for efficient resource use, good performance, and clean code. DI frameworks offer several lifetime options for different needs and situations.

I often find my mind wandering to different topics, interrupting phone calls, meetings, or reading sessions. These thoughts take center stage, making it challenging to refocus on the original task.

Interestingly, this mental game sometimes proves helpful. Whether it’s a forgotten task during a book or a work-related bug that surfaces while spending time with family, these moments can be both distracting and beneficial.

A peculiar incident occurred last week when, despite my usual preference for organic food, I accidentally purchased non-organic sourdough bread. Initially trying to ignore it after enjoying a slice for breakfast, curiosity led me to search for its ingredients. The search took me down a rabbit hole of articles and comparisons between the European Union and the United States, accompanied by alarming posters like “Stop Eating Cancer.”

The circuit breaker pattern stops a service from trying again to call another service when the previous attempts have failed multiple times. It’s similar to electrical circuit breakers that automatically cut off the current when there’s abnormal activity.

In a distributed environment, calls to remote resources may fail due to reasons such as application exceptions, timeouts, authentication issues, or overloaded systems. Usually, resilient cloud applications automatically fix these issues over time, and the calling application manages these errors using a retry pattern.

The cloud is vast. Azure docs have around a hundred thousand pages, and AWS is just as big. Other cloud providers are out there too. Each gives you lots of apps, different rules, and dozens of integrations, so creating cloud-native ones has its challenges.

They’re not identical, but big providers offer similar solutions. For example, Google Cloud Storage is like AWS S3 and Azure’s durable function is similar to AWS step functions. Details and rules can differ, but the main idea of the tech is similar, along with the challenges.

In late August, southern California faced a mosquito invasion. These tiny pests seemed to appear out of nowhere, leaving their itchy marks on unsuspecting victims. Whether you had a bug screen or not, they found their way into your home, and you’d wake up with irritating mosquito bites. At first, you might not notice them, but as time passed, the incessant itching would become undeniable.

These mosquitoes were notorious for targeting ankles, leaving small, pink, and itchy bites. Sometimes, you’d wake up with not just one or two but possibly three or more bites. The constant itching would make you want to scratch your ankles, especially when walking. It was nearly impossible to scratch them all the time, like when driving, where you’d long for relief.

Since the beginning of the pandemic, I’ve noticed a repetitive pattern of content on the internet across various platforms. Whether it’s on Reddit, different social media sites, or news websites and popular blogs, the same or similar content keeps circulating. Additionally, Google searches have taken a peculiar turn. When searching in English, the results often differ from the same websites, and in other languages like Turkish, you might encounter clickbait websites with strong SEO but weak content.