Functional / Microservices in Real-Time Financials
Recorded at:
- Share
-
- |
Read later
Reading List
Are the benefits worth the complexity?
by
Nick C
Re: Are the benefits worth the complexity?
by
Vitor Olivier
The big things we did differently:
- Our services tend to be a lot smaller and focused than the old ones
- Each entity has one clear owner through its entire lifecycle (so one specific service is the source of truth for that entity).
- Whenever entities only make sense if you look at them in combination to another, they should reside in the same service (for example a deposit and a deposit redemption)
- Enforcing the rule above makes it so a few services end up being a lot bigger than our average service. The gain, however, is that it's very rare for a service to request mutable data from another.
- Every write comes asynchronously through kafka, which means it has a clear representation of the write request. If the client needs it to look synchronous, we have probing logic to ensure it looks synchronous for them.
- We have a backend for frontend graphql service which was a game changer when developing the app.
- We used react-native, relay, and typescript for mobile clients.
After this stack matures I'll give an update on what we learned from it.
Hope this helps and thanks for watching my video!






Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think