Epilogue: Limitations and Hindsights

Reading Time: 12 minutes Since Silo, I’ve also had a lot of job interviews, where I shared the work we’ve done. I’ve met with many fellow architects. I’ve worked with people who were far more experienced than me. So in a way, I did gain a lot of insights. I’ve shared some of those already, spread along the chapters of this book. In this one, I’m going to share the very few last ones. And one last final thought.

Delivery: Reliable Messaging

Reading Time: 10 minutes In this chapter, we’re going to dive into a few more requirements for a messaging platform. As this topic is very broad, we’d be exploring only some of the concepts we should to be familiar with in order to correctly review the selection done in Silo, for the components of its messaging platform. We’d be mostly focused on messaging Reliability and meeting Silo’s product requirements, a unique case of a B2C IoT physical device.

Truthful Insights: Event-Driven Analytics

Reading Time: 9 minutes In the previous chapter, we’ve seen that these very same Events hold within them a certain truth, an immutable past. In this chapter, we’re going to see another pipeline. One who answers different needs. We’re going to build Event Analytics, to gain insights out of our Events and our product usage.

Expectations: A Customer-Driven Architecture

Reading Time: 10 minutes 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.

Best of Breeds: A Technical Architecture

Reading Time: 12 minutes 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.

Message in a Bottle: Pub/Sub Database Alternative

Reading Time: 7 minutes 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.