05 Future Changes

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.

In the last two chapters, we’ve implemented a Publish/Subscribe pattern twice. Once via a messaging platform, once with a database. Unfortunately, each implementation has its limitations. In this chapter, we’re going to mix messaging and databases together. Having each do what it does best. Ending up with a worthy candidate for a system architecture.

In a way, this chapter is a prequel. Most of what we’re about to read happened before we found the technical design. We can say it even gave birth to. Reading it after knowing the technical design is an important lesson on its own. Everything we do, comes to serve a purpose, most likely to serve our customers. The sooner we understand those, the better our designs and our system architecture will be.

In this chapter, we’re going to tie it all together. The product requirements and the technical architecture. By tying its loose ends, we’ll no longer have a candidate for it, but finally have something we can call a system architecture. Hopefully.