Best of Breeds: A Technical Architecture

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.

Expectations: A Customer-Driven 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.

Delivery: Reliable Messaging

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.

Epilogue: Limitations and Hindsights

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.