This week’s system design refresher: New Machine Learning System Design Interview Book What is Kubernetes? (Youtube video) Microservice architecture 2-factor authentication Wed assembly New Book Announcement Our new book, Machine Learning System Design Interview, will be available on Amazon on Feb/01.
Nice, series, but I respectfully disagree with the "why real-time gaming and low-latency trading applications should not use microservice architecture" post.
Yes it's not a silver bullet, no you should not use microservices in all cases. But the examples and reasons provided do not make sense.
Before zooming in, let me emphasise that microservices is an architectural style: the idea that a complex domain and its applications can be split into smaller parts that are loosely coupled. See https://microservices.io for a more comprehensive description.
Your key arguments are (1) latency, (2) stateless and (3) sockets. These are all concerns at an individual service level; not at a system level. If you want to build a stateful, low-latency / high TPS service as part of your microservices platform, by all means do so.
Where things become complex, is where distributed parts of a system (as you see in microservices, but also other systems) need to agree on a transaction. CAP theorem tells us we can only have 2 out of 3 when it comes to consistency, availability and partition tolerance (impacting performance, uptime and resiliency).
THIS is the area where you need to take decisions:
* how do you want to to manage consistency: consistent (ACID) or eventually consistent (BASE)?
* do you want to adopt a microservice pattern Y/N?
* if so, how to draw to boundaries between your domains and services (understand your domain and bounded context; use event storming for discovery)
My feeling is this was your aim with your article, given the examples of gaming/trading where this often is a major issue to tackle. But that still does not conclude whether microservices are - or are not - a good fit.
The answer is: it depends (default architect answer :) ).
* your game / trading problem domain, technology stack, and organisation building/running it may be sufficient complex to justify microservices
* your needs around transaction latency, scalability, resilience are solvable with the tools and technologies you see fit for your MS platform
PS if you would have written the article in the context of a REST architecture style, it would have made more sense. Because REST does prescribe stateless services, often is very chatty and therefore with lots of network round trips (and often assumes HTTP, although imo the transportation layer could also be socket based)
So insightful, I have learnt 3 new things today!
Nice, series, but I respectfully disagree with the "why real-time gaming and low-latency trading applications should not use microservice architecture" post.
Yes it's not a silver bullet, no you should not use microservices in all cases. But the examples and reasons provided do not make sense.
Before zooming in, let me emphasise that microservices is an architectural style: the idea that a complex domain and its applications can be split into smaller parts that are loosely coupled. See https://microservices.io for a more comprehensive description.
Your key arguments are (1) latency, (2) stateless and (3) sockets. These are all concerns at an individual service level; not at a system level. If you want to build a stateful, low-latency / high TPS service as part of your microservices platform, by all means do so.
Where things become complex, is where distributed parts of a system (as you see in microservices, but also other systems) need to agree on a transaction. CAP theorem tells us we can only have 2 out of 3 when it comes to consistency, availability and partition tolerance (impacting performance, uptime and resiliency).
THIS is the area where you need to take decisions:
* how do you want to to manage consistency: consistent (ACID) or eventually consistent (BASE)?
* do you want to adopt a microservice pattern Y/N?
* if so, how to draw to boundaries between your domains and services (understand your domain and bounded context; use event storming for discovery)
* what (sub)patterns you may or may not want to adopt, given the CAP theorem constraints. Microservices gives us the saga pattern (choreography vs orchestration based), event-sourcing, CQRS... (But there is more: https://developers.redhat.com/articles/2021/09/21/distributed-transaction-patterns-microservices-compared#the_dual_write_problem)
My feeling is this was your aim with your article, given the examples of gaming/trading where this often is a major issue to tackle. But that still does not conclude whether microservices are - or are not - a good fit.
The answer is: it depends (default architect answer :) ).
* your game / trading problem domain, technology stack, and organisation building/running it may be sufficient complex to justify microservices
* your needs around transaction latency, scalability, resilience are solvable with the tools and technologies you see fit for your MS platform
PS if you would have written the article in the context of a REST architecture style, it would have made more sense. Because REST does prescribe stateless services, often is very chatty and therefore with lots of network round trips (and often assumes HTTP, although imo the transportation layer could also be socket based)
Will there be a blog series on SAML, OAUTH2/OIDC ?
Really helpful, thank you for this! Love from India!
Subscribed and must say im really interested by this series , getting to know and learn more !
Thanks a lot
Great approach and thanks to share this with us.
TOTP was wow moment for me. I alway wondered how it works but never understood. Thanks for sharing