Frozen: Zero Throughput

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.

Bundled Tuples: Backend per Actor

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.

Frequently Fresh: When and How our Data Changes

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.

Message in a Bottle: Pub/Sub Database Alternative

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.