04 Breaking Change

In this series, we will be learning how to model multiple applications and how they relate to the very same Change Stream. To do so, we’ll be learning about applicative splits. What to consider and what would be the outcomes of the actions of splitting one application into two. We’ll see how it affects costs, scaling, reliability, hiring and many other pure technical factors. And there is going to be one unique perspective we’ll be focusing on, on how splits affect our development workflow. To do so, we’re going to start this series by learning about Bottlenecks, Throughput, Back Pressure and Upstream Pressure. Starting with something we are all familiar with - deployments.

In this chapter, we’re going to see what connects steps in our development workflow and how they affect one another. And we’re going to do so by removing Bottlenecks. Because they are everywhere.

In the next few chapters, we will be hitting two birds with one stone and learn two things at once. We’re going to inspect the effects of Upstream Pressures through the action of splitting an application, as it is one way out of many to handle it. In this chapter, we’d start with our own first split. It would be the simplest one possible, to a too convenient single application.

In this chapter, we’re going to see how splitting deployments affects our development workflow.

As the relationship between Bottlenecks and Throughput exists throughout our development workflow, it also exists between the engineers and their applications.

We’ve conveniently been through the entire series the assumption that our two applications are mutually exclusive and share nothing at all. In this chapter, we’re going to start complicating it. This time, with two applications that share a simple client-server relationship. With it, we’ll see how it also complicates our development workflow.

We’ve started talking on how to ease those consequences, by reducing the frequency of the need for our applications to Change together. One was rearranging their Modules differently between them, and we ended up seeing there are a lot of considerations to it. In this chapter, we’re going to focus on one of these. By inspecting not physical boundaries, but time boundaries. Because rolling out Changes takes time.

In this chapter, we’re going to review another split that is a technical/practical necessity. This time, we’re going to split away the other end of our backend application, the data. It’s going to persist. By doing so, we’re going to inspect the relationship formed between our application and its data.

No matter what we’ve done to ease our troubles and coding, the relationship has stayed the same. The persistent data’s structure must always meet our application’s expectations. And it needs to be maintained and managed throughout their life cycle. With this relationship solid in our mind, we can now add an application that would manage the data for us. Something called a database.

What about splits that are optional? To answer this, we’ve first had to clear out all the hard technical considerations, for that we reviewed the technical/practical musts. But before that, we’ve learned of our development workflow. On how any split affects its Bottlenecks and Throughput. And we’ve seen how splitting deployments and splitting Throughput affect it as well. And somehow everything always had something to do with the frequency of Change and the unsteadiness of the Change Stream. In the next three chapters, we’re going to put it all together. We’ll be reviewing several use cases, to learn when an optional split would be an eventually beneficial one, or otherwise.