One of the advantages of ElasticSearch is that it's easily scalable, we can replicate it easily in
communities we deploy replicated database applications, always using stateful set component.
Why?
Because Stateful Said has an additional mechanism that helps manage the replicas in the cluster database.
For example, it gives a master database and the slave databases their own sticky identities, so each
replica knows its role even after it dies and gets recreated.
It also supports directly addressing the master for right requests using a service name.
And this is important because Master is the only one allowed to write to the data so that no data inconsistency
happens.
Stateful said also supports reattaching the right storage to the restarted pod when he dies, because
instead of all applications, as the name suggests, each pod will have a state and when it restarts,
it will need the old state to continue from where it left off.
And since the state is stored in the volume with external storage, it's important that the same storage
with the previous state gets reattached to the same pod when it dies and gets recreated so that it can
load its previous state and continue where it left off.
In comparison, deployment doesn't care about all this stuff.
It manages and replicate stateless applications.
So when parts of such application restart, they always start from a fresh new state.
Also, there is no master or slave in the set up.
Each pod replica of stateless application is identical, so there's no complexity of replicating these
kind of applications.
And that's the difference between deployment and stateful, said component's.