If someone meant to say Ps and pronounce it Bees. would this confuse you :). Ps is for the P that is the start of Properties and Practice Each application should have some properties and follow certain practices. Properties: Scalable, Scale = Increase workload (horizontally scaling) Statless, no state should be shared among different application instances, Concurrency, concurrent processing = Threads. Loosely coupled, decompose the system into modules, each has minimal dependencies on each other "modularization", encapsulating code that changes together "High cohesion". API first, Interfaces, implementation can be changed without affecting other application. favor distribution of work across different teams. Backing Services, "DB, SMTP, FTP ..." , treating them as attached resources, meaning they can easily be changed. Manageable, changing the internal state and O/P via external I/P, Also regarding updating the application up while keeping the overal
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