* Support for multiple storage engines: Mysql (common), Redis (high performance), MongoDB (under planning)
* Support for multiple microservices architectures: [go-zero](https://github.com/zeromicro/go-zero), go-kratos/kratos, polarismesh/polaris
* Support for high availability and easy horizontal scaling
## Application scenarios.
DTM can be applied to data consistency issues in a large number of scenarios, here are a few common ones
* [cache management](https://en.dtm.pub/app/cache.html): thoroughly guarantee the cache final consistency and strong consistency
* [flash-sales to deduct inventory](https://en.dtm.pub/app/flash.html): in extreme cases, it is also possible to ensure that the precise inventory in Redis is exactly the same as the final order created, without the need for manual adjustment
* [Non-monolithic order system](https://en.dtm.pub/app/order.html): Dramatically simplifies the architecture
* [Event publishing/subscription](https://en.dtm.pub/practice/msg.html): better outbox model
* Support for multiple storage engines: Mysql (common), Redis (high performance), MongoDB (under planning)
* Support for multiple microservices architectures: [go-zero](https://github.com/zeromicro/go-zero), go-kratos/kratos, polarismesh/polaris
* Support for high availability and easy horizontal scaling
## Application scenarios.
DTM can be applied to data consistency issues in a large number of scenarios, here are a few common ones
* [cache management](https://en.dtm.pub/app/cache.html): thoroughly guarantee the cache final consistency and strong consistency
* [flash-sales to deduct inventory](https://en.dtm.pub/app/flash.html): in extreme cases, it is also possible to ensure that the precise inventory in Redis is exactly the same as the final order created, without the need for manual adjustment
* [Non-monolithic order system](https://en.dtm.pub/app/order.html): Dramatically simplifies the architecture
* [Event publishing/subscription](https://en.dtm.pub/practice/msg.html): better outbox model