The sharing and instant gratification economies are booming, and the companies leading these movements share at least one thing in common: They’re providing reactive applications — applications that react to users, load events, and failures on their own, without any human interaction by developers or network admins.

If you’re not familiar, reactive application engineering is a philosophy that’s rapidly gaining traction in the development community. Its battle cry is “The Reactive Manifesto,” published by Jonas Bonér, author and co-founder/CTO at Typesafe, who collaborated with a group of colleagues to outline this approach to systems architecture. To quote from the Manifesto itself:

“We want systems that are Responsive, Resilient, Elastic, and Message Driven. We call these Reactive Systems. Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.”

These types of interactions were initially championed on smartphones but have been further streamlined by wearables and the Internet of Things. Now the responsiveness made possible by these interactions is setting user expectations higher than ever. Today’s applications are required to continuously communicate on any device while maintaining 100-percent uptime and sub-second responsiveness — or risk losing their audience.

More than 7,300 developers have signed the Manifesto. And while its concepts aren’t new, explaining and organizing them for a broader audience is a big step for the engineering community. It should get us thinking about a holistic approach to building the next era of software, rather than just focusing on solving individual architectural challenges.

Many companies have prioritized at least some of these architectural elements, but could benefit even more by going reactive from end to end. I believe there are three huge advantages to be gained from being proactive about reactive application engineering:

1. Going reactive improves your user experience. Increasing responsiveness and fault tolerance is the primary reason every stakeholder in your company should support reactive application principles. By using Typesafe’s stack to rebuild our core services and by applying the underlying principles beyond code to product and infrastructure management, we’ve decreased our application’s response times from a handful of seconds to under 0.3 seconds, on average. This was achieved despite the varying structural complexity and massive quantity of the documents we manage. You can imagine the impact this has on customer satisfaction and loyalty.

2. Going reactive will future-proof your applications. Reactive principles allow you to be tech-stack agnostic so that you can reuse code as your software and the technology landscape evolve. For example, early cloud software champions like Salesforce and LinkedIn were initially developed and deployed as one giant monolithic application. Reactive application principles urge engineers to deconstruct massive applications and create a number of distributed self-contained micro-services that interoperate with each other using APIs. This makes it easier to adapt or re-platform your solution without worrying about breaking things.

An essential goal of such application architecture is to decouple and decentralize business logic into highly cohesive units that are subsequently easier to evolve independently. With such reactive practices, we were able to quickly build interoperable, independent, self-contained services on top of our core document processing IP, spanning over 500,000 lines of C++ code. With each new service, we got a chance to improve our technology stack. In this way, the growth of our technology stack itself is a manifestation of reactive application principles.

3. Going reactive will maximize your productivity. I like to say that productivity is a mindset, but it can be supported by a great toolkit. One of the exciting things about transitioning to a reactive approach is that, once developers see how quickly they can build prototype solutions, the whole team gets energized and motivated to adopt the new tools. In addition, you’ll benefit from joining an amazing community — like that of the Play Framework or Scala — which will help you attract the best new talent to your team. It’s also worth noting that reactive goes far beyond the tools you use. When your team has a collective reactive mentality for everything, from its own processes to DevOps and anything in between, iteration and innovation will happen faster than you thought possible.

The more proactively we embrace and openly champion reactive application engineering principles — both those in use today and the next wave that will undoubtedly emerge — the greater strides we can all make toward building message-driven and resilient applications that delight our users with responsiveness. I look forward to continually learning from the amazing reactive application community and sharing Nitro’s findings along the way.

Tiho Bajic is a hands-on vice president of technology at Nitro focused on building the next generation document sharing and collaboration platform for millions of users. Tiho was previously a founding engineer at Rypple (now Salesforce’s work.com) and has spent over a decade building business-critical software platforms from the ground up. Since 2011, Tiho has been a strong advocate of the Play! framework and more recently has been championing the Scala programming language. Follow him at @tihomirb.