When working in a distributed system, your overall system is comprised of discrete components which I will call "bounded contexts." Sometimes these bounded contexts have the need to be eventually consistent. In this article we will cover Out of Band Healing, a pattern that can be used to reduce temporal coupling when healing your server-side caches.

Many teams at Pluralsight use systemd for application process management. When systemd starts a process, it needs to know if the process started successfully. The most simple way to do this is for systemd to wait for a bit after starting the process (perhaps 10 seconds) and simply check that the process is still running. Since you generally can't predict exactly how long your service will take to successfully start up, this is error prone. Furthermore, this method is slow. If you are doing synchronous restarts for a rolling deploy, this adds a lot of time.

The software industry has always held a basic assumption that architecture is important. By association, the role of architect has always been esteemed important. But unfortunately, it isn't always clear what architecture is or what an architect's job should be.

In order for a technology organization to deliver products in support of a company's mission, decisions about which technology to use and how to use it must be made regularly. Creating a strategy for making these decisions is a problem for many organizations.

A crumbling code base will eventually prevent you from delivering value to your customers. What are some steps you can take to mitigate this risk?

APIs are an integral part of our distributed system here at Pluralsight. We use them to communicate between and within bounded contexts. One of our engineering team mottoes is "Be Explicit." To that end, we have a categorization system for the APIs we build and publish. This helps us know what the API is for and who should (and who shouldn't) be using it.

Pluralsight is different from most engineering organizations. We are structured differently, from what makes up a team to how we deploy code. Let's jump in and walk through a typical day in the life of a developer at Pluralsight.

You may have heard about the benefits of immutable objects, especially from the functional programming crowd. But creating and working with immutable objects in a language like C# can be tricky.

When I joined Pluralsight, I knew going in that it was going to be a different kind of company. They were already practicing things that I'd been learning about and struggling to implement in my prior company, like TDD and continuous delivery. But I didn't realize just how different my day-to-day work would be until I found that my team was doing something called mob programming.

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of their creator. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. I have 4 broad categories of tests that I keep in mind to help focus my testing.

Perfectionism and pragmatism are often at odds. How do you strike a balance between doing the perfect thing and doing the right thing?

When we started on our journey towards bounded contexts, we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them.