03 The Change Factor

What are the results of a perfectly designed experiment that was not completely executed, or not executed at all? In a binary world of success and failure, what is it? If it hasn’t succeeded, it must have failed. But it also hasn’t failed because we never executed the experiment.

There is a very interesting thread underlying and going through this entire book of The Change Factor, and it is in the story of the Monetization’s team Lambda over at RapidAPI. It was a three years old Serverless Function, worked perfectly without any issues whatsoever until one day it didn’t. Let’s reexamine this story through everything we’ve learned and tie some knots together, and see how it was frozen in time.

In the previous chapter we've seen how all of our Actors are bundled together both in our backend, and in our databases. We've also seen how and why applications do not become as reliable as a frozen application. In this chapter, we’re going to apply further actions on our design. To dive deeper into the root causes of them and try to overcome the problems discovered. And to fail doing so.

In this chapter, we’re going to take our first step towards a suitable candidate for a system architecture, by keeping our tuples of Actor-backend as mutually exclusive as can be. Doing so, we’ll learn of many more design concepts and considerations. Those not only shouldn’t be neglected, but also can be a shining light validating our designs.

In the previous chapter, it seemed like we have exhausted our efforts of pull/poll based design. In this chapter, we’re going towards push based designs. Hopefully a design based on those would be more of a worthy candidate for a system architecture.

In this chapter, we’re going to do something a little different. We’re going to first do what we’ve avoided doing so far, and store our data in a database. And in order to overcome it bundling our Actors together through the backend, we’ll try to have the database itself perform a publish/subscribe pattern on its own. By doing so, we’ll have an alternative to compare our messaging based design to.