In write through caching strategy, data is 1st written into cache and then to the database. Reference - https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/#:~:text=In%20Write%2DBack%2C%20the%20data,called%20write%2Dbehind%20as%20well. What if there is some failure while writing data to the database? Will the data in cache will be reverted too? How does this work to keep cache consistent with the database?
By definition the write-through cache should write to the database synchronously and maintain the corresponding consistency guarantees:
Write-through: write is done synchronously both to the cache and to the backing store.
For example for write-through caching the article mentions the AWS DAX:
DynamoDB Accelerator (DAX) is a good example of read-through / write-through cache. It sits inline with DynamoDB and your application. Reads and writes to DynamoDB can be done through DAX.
Which handles the cache consistency/validation for you. From the DAX and DynamoDB consistency models docs:
DAX is intended for applications that require high-performance reads. As a write-through cache, DAX passes your writes through to DynamoDB synchronously, then automatically and asynchronously replicates resulting updates to your item cache across all nodes in the cluster. You don't need to manage cache invalidation logic because DAX handles it for you.
And
If a write to DynamoDB fails for any reason, including throttling, the item is not cached in DAX. The exception for the failure is returned to the requester. This ensures that data is not written to the DAX cache unless it is first written successfully to DynamoDB.
So if you decide to use/implement write-through cache then you need to make sure that it does not store item if writing it to the database fails. How you do that - depends on the concrete technologies used, some will support that out of the box (like the AWS DAX).