Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
Similar to TWYP - An event driven architecture in a fast growing ecosystem
Similar to TWYP - An event driven architecture in a fast growing ecosystem (20)
Recently uploaded
Recently uploaded (20)
TWYP - An event driven architecture in a fast growing ecosystem
- 1. An event-driven architecture in a fast growing ecosystem November 18th 2016 Sander de Groot Sander.deGroot@infosupport.com
- 2. • “The Way You Pay” • Event driven architecture at Twyp • Common pitfalls and best practices • Looking back at our decision • Questions The next 30 minutes…
- 3. Disclaimer
- 5. • Transfer money from your mobile phone directly to another mobile phone • Near real-time pan-European money transfers • No need to be ING customer • Super simple onboarding Twyp: a social instant payments platform
- 6. Use cases
- 7. How does it look?
- 8. Some facts Countries Netherlands, Spain Users ~ 400.000 Top load 2.000 transactions per second Running services ~ 50 unique services Event catalog ~ 75 unique event types Average daily event processing ~ 420.000
- 9. Twyp is not just building an app, we are building a mini-bank. • A custom business intelligence solution • A management portal for customer support and operations • Fraud detection / prevention • System monitoring solutions And we have to operate it of course. Twyp is a mini-bank on its own
- 10. Next up: how is Twyp powered by events?
- 11. Build a new highly available, resilient and responsive platform that can be scaled on both technical and operational level Assignment for Twyp team
- 13. Simple question, the answer is: it’s complicated. However: • Fits well with our micro services based approach • It’s a great decoupling mechanism • Forces engineers to think about what they’re doing • Helps with scaling due to it’s asynchronous nature Why are we applying an Event Driven Architecture?
- 14. Event-driven communication between services
- 15. • One queue per service type • All instances listen to the same queue • Routing keys for distribution Queues and subscriptions
- 16. Event-driven all the way to the frontend
- 17. Event-driven all the way to the frontend
- 19. Time for our top 7 best practices!
- 20. <noun><verb in past tense> Why? An event describes a ’real-life’ fact that happened in the past. You can’t change the past. - Someone, some time in the past (1) Event naming convention
- 21. RegisterUser Is this a good name for an event?
- 22. UserProcessing Is this a good name for an event?
- 23. PhoneNumberInvited Is this a good name for an event?
- 24. UserAdded Is this a good name for an event?
- 25. It is not only about the name. • Any event should only be owned by one service. • Events can only be sent by that service • The data in the event is owned by the same service (2) Owner of events
- 26. • Expose which events you consume • Expose which events you are sending • Expose the commands you can handle (3) Dependencies and impact mapping
- 27. Example report about dependencies between services
- 28. Example report on event graph
- 29. There’s a few things you have to take into account with message brokers • Delivery guarantees • Idempotence • Scalability & resillience (4) Message delivery aspects
- 30. Headers • Unique ID • CorrelationId for tracing flows • Source (name of the service) • Date occurred • Authorization Body • Include only the data that is business wise part of the event. Do not put data in events because other services want to have it. For example: adding the users phone number to the PaymentInitiated event is a bad idea (5) Contents of events
- 31. • Well known solution • In case when services can’t process messages (6) Dead Letter Queue
- 32. (7) Archiving and replaying Archiving your events is of outmost importance. because You can reconstruct your state based on your events
- 33. (8) Archiving and replaying Event 1 UserRegistered[10, Sander, 0] ID Name Balance 10 Sander 0
- 34. (8) Archiving and replaying Event 1 UserRegistered[10, Sander, 0] 2 UserToppedUp[10, 100] ID Name Balance 10 Sander 100
- 35. (8) Archiving and replaying ID Name Balance 10 Sander 100 11 Richard 0 Event 1 UserRegistered[10, Sander, 0] 2 UserToppedUp[10, 100] 3 UserRegistered[11, Richard, 0]
- 36. (8) Archiving and replaying EventId Event 1 UserRegistered[10, Sander, 0] 2 UserToppedUp[10, 100] 3 UserRegistered[11, Richard, 0] 4 PaymentTransferred[4, Sander, Richard, 10] ID Name Balance 10 Sander 90 11 Richard 10
- 37. Event replayer
- 38. Event store and event replayer
- 39. So what is the impact of Event Driven Architecture for Twyp?
- 40. - Services can be run separately - Developers are forced to think about their solution - Business understands events - No long running API calls because of the async nature of events - Scalable solution Pro’s
- 41. • Requires design up front (especially if you introduce event sourcing) • More complicated frontend • Requires a completely different way of thinking • Requires some sort of task-based-ui. You have to rethink many things Con’s
- 42. Thank you for your attention! QuestionTimeStartedEvent
- 43. Building a new p2p payments platform at ING43 LAC, November 18th 2016 Sander de Groot Sander.deGroot@infosupport.co m
Editor's Notes
- We have spend two years working on our systems. I usually take more than an hour to do an introduction Now I have to do it in 25 minutes Please keep your questions until the end as there’s not much time. Afterwards I will be available A I only have 30 minutes I have set-up this presentation to quickly go over the best practices. If you have any questions I urge you to keep them until the end of the presentation. For the ones with not a lot of experience in this field it may go a bit fast. In the announcement you could have read that I’ll go into the BI solution, unfortunately I realized only after submitting the CFP that the sessions are only 30 minutes here.
- Please note that this is what we have experienced. It is in no way the only or best way to go. If you go with event driven architectures always tailor it to your situation!
- Please note that this is what we have experienced. It is in no way the only or best way to go. If you go with event driven architectures always tailor it to your situation! Also keep in mind that it has some overhead. I do not recommend to use it in all situations
- The ECB announced that they are going to introduce some kind of alias functionality for your phone number just yesterday. Although our solution is a bit different we already provide the same sort of functionality
- Things like Primary use case is for easy payments, especially in group engagement, making payments easier to your friends Party with friends, you don’t know everyone but do have their phone numbers
- These are some screens from the Twyp app. As you can see it really is a separate brand and it takes a compeletely different approach from other ING apps
- I can’t discuss the actual numbers but these are some stats I can share
- The ECB announced that they are going to introduce some kind of alias functionality for your phone number just yesterday. Although our solution is a bit different we already provide the same sort of functionality Multiple countries
- When we started the project we were more or less given the assignment to … So we presorted and started with a web scale architetucture Technical = scaling technically Operational = being able to quickly create new features, a/b testing, new team members
- We based our application (including frontend) on the reactive manifesto. For those we do not know the reactive manifesto describes what reactive systems are and how they should be build Also see http://www.reactivemanifesto.org/ Today we will focus on the message driven part.
- It allows us to easily scale (both technical and organizational) It gives us a great way to decouple services It allows us to talk in business operations (as events are facts that happened) When you get to know it, you’ll notice it’s a quite natural way of thinking about things It allows us to easily extend our system
- Services do not directly talk to each other, they use events to inform the world (not ncessarily each other) about things that happened. Email lijsten
- Moeilijk te lezen
- It allows us to easily scale (both technical and organizational) It gives us a great way to decouple services It allows us to talk in business operations (as events are facts that happened) When you get to know it, you’ll notice it’s a quite natural way of thinking about things It allows us to easily extend our system
- A gross over simplification of the actual situation..
- Put an image of the general architecture here (communications) Every service has it’s own database with it’s own data! Very important Split this into multiple slides
- We’ve learned many best practises along the way in order to suppor tthis event driven architecture.
- I could ask the public some of them
- I could ask the public some of them
- I could ask the public some of them
- Yes, this name adheres to the rule. However we try not to be a CRUD application, try to use useful names.
- Afkortingen
- One of the most important things in architectures is how can you determine the impact. This is especially true with event driven architectures where you’re working with micro services.
- One of the most important things in architectures is how can you determine the impact. This is especially true with event driven architectures where you’re working with micro services.
- One of the most important things in architectures is how can you determine the impact. This is especially true with event driven architectures where you’re working with micro services.
- Working with AMQP requires a well thought through solution. Think CAP theorm, two-phase commit, acknowledgements, publisher confirms
- Why? Always useful! To discuss Event store Event replayer Event sourcing Veel informatie.
- Why? Always useful! To discuss Event store Event replayer Event sourcing
- Why? Always useful! To discuss Event store Event replayer Event sourcing
- Why? Always useful! To discuss Event store Event replayer Event sourcing
- Why? Always useful! To discuss Event store Event replayer Event sourcing
- Why? Always useful! To discuss Event store Event replayer Event sourcing Veel informatie
- Why? Always useful! To discuss Event store Event replayer Event sourcing Veel informatie
- We’ve learned many best practises along the way in order to suppor tthis event driven architecture.
- Foutmeldingen eindgebruiker
- We’ve learned many best practises along the way in order to suppor tthis event driven architecture.