Building Reactive Systems

Transcript

1. Building Reactive Systems @jeduardocosta
2. About me - Eduardo Costa - 99ner - Backend developer - Scala enthusiastic - @jeduardocosta
3. Agenda - Demystifying Reactive - Back-pressure - Circuit breaker - Event Driven Architecture - Event Sourcing and CQRS - How can we start?
4. Demystifying Reactive
5. What's the meaning
7. Reactive is an architectural and design principle, not just a library
8. Reactive Manifesto
9. Reactive Manifesto
10. Reactive Programming vs Reactive Systems?
11. Reactive Programming
12. Reactive Systems
14. They can and should be used together
15. Back Pressure
17. Back
18. Back Pressure
21. Back Pressure // Getting a stream of jobs from an imaginary external system as a Source val jobs: Source[Job, NotUsed] = inboundJobsConnector() jobs .buffer(1000, OverflowStrategy.backpressure) .map(url => pipeline(Get(url)).map((url, _))) .mapAsync(4)(identity) .map(parseUrls) .mapConcat(identity) .runWith(Sink.foreach(println)) OverflowStrategy.dropBuffer | OverflowStrategy.dropHead OverflowStrategy.dropTail | OverflowStrategy.dropNew
23. Circuit Breaker
24. You don't need wait for failures If you're going to fail, fail fast
25. Circuit Breaker
26. Circuit Breaker class DangerousActor extends Actor with ActorLogging { import context.dispatcher val breaker = new CircuitBreaker( context.system.scheduler, maxFailures = 5, callTimeout = 10.seconds, resetTimeout = 1.minute).onOpen(notifyMeOnOpen()) def notifyMeOnOpen(): Unit = log.warning("My CircuitBreaker is now open, and will not close for one minute")
27. Event Driven Architecture
28. "Event-Driven Architecture (EDA) is a design paradigm in which a software component executes in response to receiving one or more event notifications" (Gartner)
32. Event Sourcing and CQRS
36. The good part - No need for mapping between domain objects and database representation - Easy to test and debug - Production troubleshooting - Audit log for free - Scalability allowing scale out bounded context separately - Handle complex domain separating read and write responsibility
37. The bad part - Unfamiliar model - Defines events can be hard - Versioning - Eventual Consistency
38. Event Sourcing and CQRS Actions() .onCommand[SubmitPaymentStatus, Done] { case (SubmitPaymentStatus(userId, status), ctx, _) if userId == transaction.creator => status match { case PaymentInfoStatus.Approved => ctx.thenPersist(PaymentApproved(transaction.itemId))(_ => ctx.reply(Done)) case PaymentInfoStatus.Rejected => ctx.thenPersist(PaymentRejected(transaction.itemId))(_ => ctx.reply(Done)) } case (_, ctx, _) => ctx.invalidCommand("Only the auction creator can submit payment status") ctx.done } .onEvent { case (PaymentApproved(_), _) => Some(transaction.updateStatus(PaymentConfirmed)) case (PaymentRejected(_), _) => Some(transaction.updateStatus(PaymentPending)) }
39. How to design domain model?
40. Domain Driven Design
41. Domain Driven Design
43. How can we start?
44. Steps - Embrace reactive principles - Asynchronous processing with Streams / Back-pressuring - Start with reactive programming - Use circuit-breaker - Don't build microliths - Events over states (Event Sourcing and CQRS)
46. References - CQRS Journey (https://msdn.microsoft.com/en-us/library/jj554200.aspx) - How Events Are Reshaping Modern Systems - Jonas Bonér (https://speakerdeck.com/jboner/how-events-are-reshaping-modern-systems) - Lessons Learned From PayPal: Implementing Back-Pressure With Akka Streams And Kafka (https://www.lightbend.com/blog/lessons-learned-from-paypal-implementing-back-pres sure-with-akka-streams-and-kafka)
47. That's all folks @jeduardocosta