Microservices design patterns

Editor's Notes

• #2: So far we discussed benefits and challenges of MSA. Those benefits wouldn’t come for free. You need to design your app in a way that you get most out of it. Same as challenges, you can design your app to deal with them. Let’s talk about how we can design your application. You can copy&paste code or script but not design.
• #3: How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment
• #5: Augmenting core functions with sidecar, configuring NGINX etc.
• #6: Ambassador = Forward proxy collocated with comsumer
• #7: Envoy works with control plane to provide these features.
• #17: ADLS is not designed for random read
• #19: Connection pool to DB Thread pool
• #20: 1 CPU= 1 Azure vCore These numbers should be based on perf/stress/soak testing Similarly you can configure resource quotas at namespace (Test vs Prod)
• #21: If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
• #22: If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
• #23: If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
• #24: Semantics between two context are often different, especially with old system. New model would corrupt by dealing with lots of old models in ad hoc fashion. 3 logical components in implementing ACL. Façade is normally given as framework/platform
• #25: Strangler is the stuff that covers the tree, so you don’t see what’s inside.
• #26: The problem that this pattern solve is this. Users used to access this feature in the old app but now it’s moved in to the new app. We use it as analogy here. From outside the system, users don’t see what’s going on inside the system.
• #30: How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment