[usr42]

I totally agree with your analysis. All the options only work if you have the right constraints and prerequisites. Option three can be a valid use-case if you already have multiple (stateless) replications of your application running in parallel. For instance in a typical microservice architecture this is usually the case. A restart of one of the replications should then not impact the SLA. In a real-life scenario it could of course be a bit more complicated. If all the replications where started at roughly the same time, the expiration could still result in an outage.

The next blog post has more restricted prerequisites (HikariCP as connection pool, which only supports JDBC), but solves the problem more gracefully. I hope I can finish this blog post soon.

A repository with the example code is already existing. If you are interested, here is the link: https://github.com/usr42/spring-vault-database-rotate

[tonnydan]

It is correct that one service application down in a services' cluster would not cause the service itself be offline, but the capability of processing requests will be impact. That is what I said which will impact on the SLA. And also, the reboot may not be predicted, which might be the fatal problem.

[usr42]

The reboot option is definitively not the right choice for all use cases but could be an option, depending on your constraints. At least it is still better then just not handling the expiration at all.

I think the follow-up post fits your needs better because no restart and so no downtime is needed. Hopefully I can finish it the next days.