A system is responsive if it gives results in a reliable manner. If you talk to me, I will answer your question or, at least, tell you that I do not know the answer or that I was not able to understand the question. Better if you get the answer, but if a system cannot give that to you it is still expected to give something back. If you have past experience with client operating systems from just ten years ago and some old computers, you can understand this. Getting a rotating hourglass is frustrating. You just do not know whether the system is working to get you the answer or is totally frozen.

A reactive system has to be responsive. The response should come in a timely manner. The actual timing depends on the actual system. It may be milliseconds, seconds, or even hours in case the system is running on a space ship travelling towards the other side of Jupiter. The important thing is that the system should guarantee some soft upper limit for the response time. This does not necessarily mean that the system should be a real-time solution, which is a much stricter requirement.

The advantage of responsiveness is not only that the user does not become nervous in front of the computer. After all, most of these services are used by other services that mainly communicate with each other. The real advantage is that error discovery is more reliable. If a reactive system element becomes non responsive, it is certainly an error condition, and something should be done about it, out of the scope of normal operations (replace a faulty communication card, restart a system, and so on). The sooner we can identify an error state, the cheaper it is to fix it. The more we can identify where the problem is, the less time and money we could spend localizing the error. Responsiveness is not about speed. It is about better operation, better quality.