Reactive Design Pattern
•Download as PPTX, PDF•
0 likes•16 views
Introduction about Reactive Design Pattern
Recommended
Recommended
More Related Content
Similar to Reactive Design Pattern
Similar to Reactive Design Pattern (20)
More from Xuân Thu Nguyễn
Recently uploaded
Recently uploaded (20)
Reactive Design Pattern
- 2. Hello! I am ThuNX Programming & Photography Find out more: @hitamu
- 3. AGENDA ■ Why Reactive? ■ Reactive Manifesto ○ Reacting to users ○ Reacting to failure ■ Tool of the trade ○ Functional programming ○ Existing support for Reactive design
- 4. 1. Why Reactive ? Reactive system
- 5. Structure of Reactive values
- 6. Coping with load Gmail application ■ Storing emails ○ Exabytes of storage ○ Distributed machines ■ Sharding pattern ○ Sharding with location ■ Ability to scale ○ Adding more node
- 7. Coping with failures Keep running when things go wrong ■ A machine may fail ■ Network components may fail ■ Human operators fail => Replication
- 8. Reactive system challenges ■ Network connectivity is poor ○ Circuit breaker pattern ■ Overloaded service ○ Flow control ■ Avoiding the ball of mud ○ Message flow ■ Integrating non-reactive components ○ Resource-management patterns
- 10. Reactive Manifesto ■ Responsive ■ Resilient ■ Elastic ■ Message-driven
- 14. Reacting to failures ■ Software will fail ■ Hardware will fail ■ Humans will fail ■ Timeout is failure
- 15. Reacting to failures ■ Using circuit breakers ■ Supervision ■ Losing strong consistency ■ ACID 2.0 ■ Accepting updates
- 16. 3. Tool of the trade A brief history of time...
- 17. Functional programming ■ Immutability ■ Referential transparency ■ Side effects ■ Functions as first-class citizens
- 18. Existing support for Reactive design ■ Green threads ■ Event loops ■ Communicating Sequential Processes ■ Futures and promises ■ Reactive Extensions ■ The Actor model
- 19. Actor model ■ Inherently asynchronous ■ Fault tolerance via supervision ■ Location transparency ■ No concurrency within one actor
- 20. Conclusion
- 21. Summary ■ Why Reactive? ■ Reactive Manifesto ○ Responsive ○ Resilient ○ Elastic ○ Message-driven ■ Tool of the trade ○ Functional programming ○ Existing support for Reactive design
- 22. Next ● Fault tolerance and recovery patterns ● Replication patterns ● Resource-management patterns ● Message flow patterns ● Flow control patterns ● State management and persistence patterns
- 23. Next ● Message passing ● Location transparency ● Divide and conquer ● Principled failure handling ● Delimited consistency ● Nondeterminism by need ● Message flow
- 24. Next ● Fault tolerance and recovery patterns ● Replication patterns ● Resource-management patterns ● Message flow patterns ● Flow control patterns ● State management and persistence patterns
- 25. THANK YOU
Editor's Notes
- It must react to its users (responsive). It must react to failure and stay available (resilient). It must react to variable load conditions (elastic). It must react to inputs (message-driven).
- You can do that by equipping every user with an ID that expresses geographical affinity (for example, using the first few digits to denote the country of residence), which is then mathematically partitioned into the correct number of shards (for example, shard 0 contains IDs 0–999,999; shard 1 contains IDs 1,000,000–1,999,999; and so on). This means that by splitting a system into distributable parts, you gain the ability to scale the service capacity, using a larger number of shards to serve more users. As long as the shards are independent from each other, the system is in theory infinitely Coping with failures 7 scalable
- Replication is a more difficult same data in multiple places replicas synchronized high cost. Should writing to the nearest location fail or be delayed if a more distant replica is momentarily unavailable? Should it be impossible to see the old data on a distant replica after the nearest one has already signaled completion of the operation? Or should such inconsistency just be unlikely or very short-lived?
- Between the front end that runs on the users’ devices and the web servers that provide access to back-end functionality Between the web servers and back-end services keep the user visible part of the application responsive under all conditions The service decomposition shown in figure 1.2 is too coarse-grained to serve as an example for a “ball of mud,” but an illustration for the principle of message-flow design would be that the service that handles email composition probably should not talk directly to the contact pop-up service: if composing an email entails showing the contact card of someone mentioned in the email, then instead of making the back end responsible for that, the front end should ask for the pop-up, just as it does when the user hovers the mouse pointer over an email header. In this way, the number of possible message-flow paths is reduced by one, making the overall interaction model of back-end services a little simpler.
- Reactive systems must be responsive The system should respond in a timely manner. Responsive systems focus on providing rapid and consistent response times, so they deliver a consistent quality of service. Reactive systems must be resilient In case the system faces any failure, it should stay responsive. Resilience is achieved by replication, containment, isolation, and delegation. Failures are contained within each component, isolating components from each other, so when failure has occurred in a component, it will not affect the other components or the system as a whole. Reactive systems must be elastic Reactive systems can react to changes and stay responsive under varying workload. They achieve elasticity in a cost effective way on commodity hardware and software platforms. Reactive systems must be message driven Message driven: In order to establish the resilient principle, reactive systems need to establish a boundary between components by relying on asynchronous message passing. Those are the core principles behind reactive programming put forward by the manifesto. But there’s something else that supports the thinking behind reactive programming. That’s the standard specification on reactive streams.
- The front-end server for images first checks an in-memory cache, then attempts to retrieve the image from storage, and finally returns a fallback image if neither is successful.
- Using standard listener threads and a connection pool results in the listeners acting as queue entries, with overflow into the system TCP buffers.
- Adding an explicit queue to manage access to the database connection pool allows you to manage the maximum system latency separately from the listener thread pool size and the connection pool size.
- Delimited consistency 8.1 Encapsulated modules to the rescue 8.2 Grouping data and behavior according to transaction boundaries