Was co-written by Tal Tsur
Persistency is one of the most annoying aspects of software design and development. Seriously, why do we constantly need to stress, “I must maintain my state; I must preserve my data,” just in case an app happens to crash?
Not to mention that persistency solutions are expensive and systems with local persistency usually suffer from ongoing performance degradation, relying on complex code required for in-depth testing scenarios. Such systems are also based on complicated design and implementations in the main flows, complex troubleshooting, and potential integrations with third-party solutions. So what to do? There’s a better way, and it’s called Persistency Free Architecture.
The problem with persistency
Apply persistency to another job and its faults are clearer. Imagine a furniture factory in which workers have to write down the steps for building a chair over and over again. They do this so that they may take breaks, return back, check their notes, and start quickly to work from where they left off. Workers invest costly time to write down their steps for minimal gain, as these steps are only used after breaks.
Returning to the world of software, developers invest valuable time to keep track of their state, simply to mitigate “worst case scenario” crashes. This is a waste of both valuable time and resources. Now, imagine there was an application that could conduct business tasks without the need for persistency. The end result would be a much more efficient and robust solution.
It’s what we call Persistency Free Architecture.
How it works
The core of the concept is a new software design schema that builds up a software solution that is capable of self-restoring its “required state,” as opposed to local persistency. In some cases, the required state will be sufficient to continue the desired work. In other cases, it may be the last known state.
Practically speaking, most software products implement a local persistency solution in order to maintain their state in the event of a system crash. At the same time, these products function as an integral part of a greater system. Such systems usually include their own central persistency solution, such as a central database or central file system storage, utilized by all surrounding services. Thus, in order to avoid relying on your own local persistency solution, one of the following two approaches can be applied instead:
- Restore: Design a local recovery solution that can effectively leverage only the central persistency solution, and is able to restore and continue from the necessary (current) stage.
- Ignore and continue: Ignore the current state and simply continue from the last good known state, as defined by the software. This takes into consideration that portions of completed work may be lost and will require repeat processing.
Using the furniture factory example from above, we can see the benefit of Persistency Free Architecture for the workers. With this new schema, they can, in fact, build chairs without documenting their every step. Instead, they can either restore or ignore and continue.
Restoring would mean examining the last uncompleted chair they were building, understanding where they stopped, and continuing from that point. They are investing more time when they return from breaks, but their routine work is more efficient.
If they ignore and continue, they’ll throw out the uncompleted chair and simply start a new one. It may be a waste of materials, but they are much more efficient both during their routine work, as well as after their break.
Persistency Free Architecture is a fresh design concept and development approach that focuses on business flows, eliminating the need to constantly worry about persistency. The motto is quite simple: “Prefer smart recovery over expensive persistency.”
Let us know what your think of Persistency Free Architecture. Are there alternate solutions to solving the persistency hassle? We look forward to hearing your feedback on this exciting new concept!