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.
Reading Time: 10 minutes Security is not a joke at all. At least not for a small startup company, intending to create a B2C smart kitchen appliance. But the way we handled it started with a joke. A joke that eventually was on me. I had to make it so.
Reading Time: 19 minutes In this chapter, we’ll be reviewing the decisions made for composing Silo’s messaging platform. We’ll start with the PoC stage, and move to its full implementation with its data pipelines.
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.
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.
Reading Time: 10 minutes The fusion we’ve done between Event-Driven Development, Reactive Manifesto and Enterprise Messaging Architecture, brings an interesting twist to why and how we store Events. It also uncovers a certain truth.
Reading Time: 10 minutes 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.
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.
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.
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.