When traveling, we always think of our traveling bag. How our luggage will fit in it, yet have you ever thought, How your bag will be stored or transferred. I think data should be thought of same way. How it will be stored and how it will be retrieved. also sizing would matter, How much size data will occupy. Would it fit in one server or will we need a cluster. Many question would jump in your mind, yet storing and retrieving is the most general one. And so we'll move to ask SQL or NoSQL, I'd go for SQL in-case of having multiple entities communicating with each other, having multiple relation between one another. Yet if what I need is a storage unit, then NoSQL would be my choice. Have a look on the CAP theorem and how each of consistency, availability and partition tolerance will be satisfied using the DB engine you choose
If we were to talk about old messaging system where there exist post-office, postman & mailbox. each component had its own functionality that we looked for when trying to visualize how those component where to interact in a computerized version. Simple scenario: Mail is added in mail box Postman arrive pick mails from his area mailboxes and take them to the post-office. Post-office organize mails by areas. Postman takes mails related to his area "distribute it in mailboxes". A person can go to post-office and pick his own mail "in case of failure or wishes for early delivery". Mapping in a computerized version: Scenario: Observer design pattern which can use push or pull scenario, to inform those whom are registered for an event about its occurrence. Component: Post-Office = Message-Broker Post-Office-Box = Message-Storage-Validity Mailbox = Topic/Queue Postman !!! where's the postman ? Apache kafka act as a message broker which d