How we're trying to develop a new chat service through WebSockets at letgo coming from a monolithic REST API. The challenge: Maintain the backwards compatibility. We don't want to force the mobile app users to update in order to use the new system. Furthermore, we have a lot of uncertainty on how the new system will perform, so in order to reduce it, we're taking advantage of an Event Sourcing approach in order to process in the new chat system in the staging environment the actual production load of the current system. If you want to learn more about the whole process we've followed and not just the synchronization part, come to the Software Craftsmanship Barcelona! This time we (@SergiGP and me, @JavierCane, will try to explain some more interesting things about how we're trying to develop this new chat system and, maybe you could bring some interesting discussion points :D). I'll do a video summarizing some of the talk conceptos for the http://codely.tv video blog, so stay tuned! http://twitter.com/CodelyTV

1. Leaving The Monolith
thanks to Event Sourcing
Migrations, Event Sourcing, AWS, and other things of the meter
@JavierCane#scpna - Software Craftsmanship Pamplona

2. @JavierCane#scpna - Software Craftsmanship Pamplona
Saliendo del monolito,
al Rico Eventito
Migraciones, Event Sourcing, y otras cosas del meter

3. Welcome!
I’m Javier Ferrer González
@JavierCane

4. Greetings to Sergi!
@SergiGP
Welcome!

5. Contents
! Starting point
! Needs
! Action plan
! Flow example
! Conclusions

6. 1.
Starting point
Context

11. Starting point
Context
! Mobile first application
! Crazy growth (ads in TV in USA and Turkey)
◕ External services (Parse, Kahuna…)
◕ In-house API
! Where do we go
◕ Microservices architecture
◕ Event Sourcing
◕ Orchestration Layer

12. 2.
Needs
New chat system!

14. Needs
New chat system!
! From:
◕ REST API
◕ “Chat” (messaging system)
! To:
◕ WebSockets (better UX)
◕ Chat
◕ Isolated from API service
◕ Backwards Compatible (mobile!)
◕ Scale!

15. 3.
Action plan
Maintaining Backwards Compatibility (BC)

16. Action plan
Maintaining BC
! Develop new chat with Scala and Akka, and WS
! Maintain BC taking advantage of Event Sourcing

17. Action plan
Maintaining BC

18. Action plan
Maintaining BC

19. Action plan
Maintaining BC
! Why not sync through DB?
◕ Share DB: K.A.O.S.
◕ Doesn’t scale
◕ Coupling

20. Action plan
Maintaining BC

21. Action plan
Maintaining BC
! Why not sync through SQS?
◕ Doesn’t scale

22. Action plan
Maintaining BC

23. Action plan
Maintaining BC
! Why?
◕ Scale
◕ Decoupled
◕ Open-Closed Principle compliant at a services level

26. 4.
Flow example
Maintaining BC

27. From the new chat to
the legacy one

28. Flow example
Maintaining BC

29. From the legacy chat to
the new one

30. Flow example
Maintaining BC

31. 5.
Conclusions

32. Conclusions
! Event Sourcing ~~ DIP at a services level
◕ Dependency Inversion Principle (CodelyTV video)
◕ Allow OCP: One SNS publishes to many SQS
◕ Encourage SRP
◕ Decoupleeeeee

33. Conclusions

34. Conclusions
! Isolated services
◕ Different technologies
◕ Different context
◕ Change context => Mental challenge
! AWS vs RabbitMQ
◕ Go fast => AWS
! From PHP to Scala: 🙃 🙂 🙃 💃 🙃 😀 😐 😳 🤔 🙂 🙃 🙂 …
! Know more at #SCBCN16! (October 1st & 2nd in BCN)

35. References / To take away
! A Series of Fortunate Events
! The anatomy of Domain Event
! 6 Code Smells with your CQRS Events and How to
Avoid Them
! json:api standard
! Sending Amazon SNS Messages to Amazon SQS
Queues
! Subscribing a Queue to an Amazon SNS Topic

36. Questions?
Thanks!
Contact
@JavierCane || @SergiGP
javier.mailserio@gmail.com
Codely.TV

37. Credits
! Presentation base template by SlidesCarnival
! Graphics generated using draw.io