Before we start talking about application’s architecture with dinemic framework, let’s take a short look on common, very popular application architecture
Standard application architecture
Usually your application (web, standalone, android) has following parts:
- Database – stores data globally, for whole application
- Controller + View – displays and controls access to the data in user friendly form (UI) or in computer friendly form (API)
- Optional: load balancers, storage for large files and so on…
Sometimes, when you want to improve performance, you need to add load balancer, some configuration files and other stuff, that makes your application failure proof. Finally architecture of such application might look like this:
In large, corporate applications it is very common to integrate also identity services, split responsibilities for different services and many more, which makes final application very compels.
When it comes to hardware failure and split brains, detached part of cluster might stop working and will be not synchronized with rest of cluster. In applications that are something more than software (IoT, communication, etc.) this might cause that hardware is also in different state than database shows. To prevent such failures, expensive hardware is necessary to buy to support cluster sustainability.
Finally, HA architecture with redundant component might look like:
With dinemic framework you can get scalability and decentralization for free. Dinemic framework is kind of ORM for key-value database. Each node has its own copy of database synchronized with other nodes.
Synchronization is done after every change in any object in database, so you can recreate any object from scratch in any point of cluster to start your application there. Security is provided by cryptographic keys, assigned to each particular object registered in framework, transparently for the user and developer.
Also very detailed resource management is given without any additional effort to developer. And, what is important, this is based not on database permission table, but on cryptography. In dinemic, granting or revoking permissions, securing data and group permission management for any object causes cryptographic modification of encryption keys for interested objects. That leverages security to next level.
Any kind of split brain will no longer cause your cluster failure. Once cluster is divided, two its parts works on last known set of data. On re-join all modifications are applied with respect to blockchain-like data synchronization mechanism, also based on cryptographic tools.
|Common architecture||Dinemic app architecture|
|Failure proof||Low or medium with expensive hardware and complex configuration||Very high, no single point of failure, trivial node replacement|
|Split-brain proof||Low, any split brain might corrupt data or other hardware state||VEry high, internal mechanisms and application architecture prevents damages during split brain and after rejoin|
|Backup||Necessary external tools, sometimes very expensive||Each cluster node has full copy of data with history in form of block-chain|
|Scalability||Complex, usually very expensive||Guaranteed by framework|
|Security||Requires additional effort, usually expensive||Guaranteed by underlying framework, managed by cryptography|
|Performance||Might be high after implementing right, usually expensive solutions||Medium, depends on hardware and networking performance. With proper configuration of cluster domains might be very high|