Deciding on an architecture has to be a very big deal. Two, three or more layers? What database to use: SQL, NoSQL or NewSQL? You want some messaging with that setup? In many companies there are entire departments dedicated to deciding on an architecture and then refining it until it’s perfect. But the fact remains that there is not a perfect architecture for all situations, and probably not even for a particular situation. The modern stack has very stringent requirements of functionality, scalability, and cost, which keep changing all the time. So why do we expect a rigid architecture to thrive in such a changing environment?At MediaSmart Mobile we have to answer many thousands requests per second under very stringent conditions, plus add new functionality all the time to remain ahead of the competition. We might expect our architecture to support anything we throw at it; instead we allow it to reflect the changing conditions and evolve as needed. Nothing is sacred: from databases (where we have performed several large-scale migrations in two years) to configuration or even hosting company, we are open to any changes that might increase our scalability and/or lower our costs. The key is to keep our architecture fluid, instead of committing to past decisions.We will illustrate the principles of the fluid architecture with real-life examples using Node.js.