Hmmm Enterprise Patterns tiring but useful

Request-Reply

Consumer / Producer with Request - Reply Channel
Multiple Consumers / single producer with Request-Reply Channel

Return Address
Consumer specifying return address in the request message. Producer sends the response to the return address
Request getting consumed by more than one service provider

Correlation Identifier
Each message is having Message Id, CorrelationId, Business Id (ex: orderId)
Provider copies the these id's to the replies

Pipes and Filters
There is always queue / pipe / channel between filters i.e. the sequence of execution

Context-based routers
Based on context routed to multiple service providers and output channels

Splitter
Splitting the messages into individual message consisting data for one item

Splitter-Router
This is combination of splitter and context-based routing

Aggregator
Multiple services responses are combined together by aggregator (example: for completing order we may have to do multiple tasks, aggregate the response and send the response)

Scatter-Gather
Example: Sending quote to multiple lenders and sending final quote that is with lowest rate of interst

Composing Patterns
Combination of Splitter -  Scatter-Gather 

Redis capabilities - I'm impressed

1. Optimized for speed - Single threaded event loop
2. Data structures are implement for maximum performance, constant time and space
3. Binary safe - human readable text to encoded binaries
4. Size - 0 bytes to 0.5 GB
5. Key based access - using GET and SET semantics
6. Multi key operations
7. Atomicity of operations
8. Data expiration - TTL (Time to Live) support. These keys are called volatile keys (Advantages: effective invalidation approach and keeping cache size under control)
9. Configurable eviction policies (all or only volatile keys) - Supports random or usage based eviction policies
10. Intelligent caching - can managed via commands on server or LUA scripts
11. Distributed network server - uses TCP protocol
12. Request pipeline - i.e. batch process to boost average request per pipeline
13. Master - Slave architecture
14. Highly available - Replication mechanism through slave. Watchdog and management processes failover when needed
15. Persisting data to durable storage - supports optimal and tunable data persistent mechanisms. Also can create snapshots of cache at any moment in time and restore to instant before outage
16. Horizontal scaling support for RAM, Computation or Network resources via Sharing
17. Local cache replicas - can be run on application servers and can be used for local caching. Replication can be used for local replicas for central shared cache.
18. RLEC - Redis Lab Enterprise Cluster acts as container that can run multiple redis databases in a highly available and scalable manner.
19. Zero touch service deployment - cloud (AWS, GCP, Azure, IBM) based deployment
20. https://redislabs.com/redis-enterprise/technology/redis-enterprise-cluster-architecture/
21. https://redislabs.com/redis-enterprise/technology/redis-enterprise-cluster-architecture/