"I NEED data from another service!"... Do you really?

But shouldn't a service be stateless? Doesn't a cache make it have a state?

No Code example ?

Several years ago, a senior software designer told me about Pull-Push mechanism, up to now that term still sticks in my head.

what is wrong with just reading from the database

You're in Canada? I never would have figured that oot. ;)

Great video my man, seriously.

How would you handle situations where some servers are down when calling multiple endpoints from the client in your data ownership exanple? For instance, while the shipping service is down, I would expect the ordering service to continue working. However, the approach you described would result in a failure of the client's ordering process and may require compensacting transaction.

What if the data is volatile and we really need to get the data from another service? Only rpc and request response?

Thanks for the video, again, this channel makes programming better! How do you deal with a situation, when you need to get data from a service, but depending on some conditions, owned by the other service? e.g. I need all the orders, shipped in a specific date range? This might require require large amount of data to be transferred between the services.

Interesting video. How do you ensure that when the event from "ordering" reaches "shipping" all the "shipping" information is already in the "shipping" database? Could you have a race conditioner there, or the "client" is orchestrating the first steps(generating ID, saving ordering data, saving shipping data, and finally placing order) in a synchronous way?

CodeOpinion design architecture for real chad

Domain events

Why use cache instead of db table?

Can you extend the video where ahipping options depends on the weight or size of the order. Then after that, also define rules where the price of certain shipping methods depends on the total amount of the order. Finally define a reasonable api for a UI to display to customers to nudge e.g. large order to get free shipping. I know this is a mouthful but it'd be cool to go a level deeper in complexity

Leaving this flow to the customer won't expose things it shouldn't? The client could not send the information to the shipping or send any other id there, wouldn't it break everything?

Great points but I strongly believe the cache for exchange rates should be maintained by exchange service team and not order service team. Order service team really should not determine the data quality of exchange rates from another service

Great video and I like the new studio setup and lighting :D

This video contains a lot of good information. It's so easy for me to recommend your channel to others. Please keep up the great work.

So relevant. Last two organizations I’ve been working with the last two years have had this issue. Both of them had workflows with this issue. Tying availability to several network separated components, increasing load on these components and creating difficulties when considering retries.

Thanks for the video! I'm thinking about a provider agnostic payment micro-service. Let's say I want one place where all payments flow through and the service returns either payment success or payment failed result. Different providers require different information, for example:

-Stripe requires card token information
-PayPal requires order item information

In your opinion, would it make sense to setup separate services such as a Stripe integration gateway, PayPal integration gateway, provider x integration gateway etc. Then pass something like the order reference through the payment microservice, and allow the specific integration gateway to use that reference to gather specific data required from other services before making the call to the external payment provider.

Great video!!

So if we are having user-service which manages login/sessions and user info and there are other bunch services that are dependent on user-service for user info, does that qualifies the user info as a reference data for other services?

What about a scenario where you have a business rule that must be enforced in 2 different boundaries/services? For example, we have Orders and Subscriptions boundaries. Whenever you buy something, what you are buying is a Price. If the Price has a recurring frequency, then, after Ordering, you create a Subscription of that Price. Well, theres a business rule that says that a subscription can have more than one Price, but those prices must be of the same frequency (for instance, two Daily Prices, or two Monthly Prices, but not a Daily Price and a Monthly Price). Orders, whenever you create an Order, you have the exact same requirement. So, it seems to me that we need to have Price in both boundaries and the Frequency.
In this case I cannot have a cache... I have business rules to enforce, and the business rule is the same. Whats the better way to approach this? I was thinking about making the Price aggregates in both boundaries but only allowing one boundary to change the Frequency, but it still doesn't seem right. Particularly because i want everything to be as async as possible through messaging. But if the frequency changes, eventual consistency could be a problem because the business rule could not be correctly validated in one of the services because of stale data.

Great content with explicit explanations. I love it. Thanks

Considering your last example but from the point of view of the Credit service.
Imagine that this service is responsible for calculating the score based on Sales service.
Should it store the data of sales ahead of time or directly call the Sales service in time of calculating the score?

How do you handle new services that need reference data, but missed out on the events? Would be nice to see a video on that.

I would like video on a pattern I loathe - Central Configuration Service.

The stated reasons are often:
- I need one place to change everything
- Avoid duplication of "configuration data"
- Usually a clickity-click GUI (git/svn is too difficult)

The real reasons and issues are:
- Afraid of making changes - commit, build, test and deploy - so we need a way to bypass all that "structure and rigor".
- Overly complicated processes, bad culture, CCB, CAB, ST, RM, etc...
- Not knowing where to place some set of "configuration data" (ownership) and lack of business domain modelling.
- Not understanding the difference between static data, environment, deployment and runtime configuration. Conflating it all to "configuration/metadata", just like the common/utils anti-patterns.
- The services need to integrate towards this CCS API that becomes a single-point of failure at runtime.
- Then we end up having to implement audit, access-control, versioning, undo, and structures and in the end re-invents a graph database in MongoDB, that we now also need to have backups of.
- And finally we loose control over which services has access to which "configuration", in what format/structure/schema because it's just a centrally shared database, but hiding behind an API, and no-one owns "schema".

My take:
1. If we have some set of "configuration data" that is static, smallish and changes a few times per month - just put it the same repo/binary/package; commit, build and deploy as needed.
2. Environment configuration can go into a central system, but I think it should be the deployment/provisioning systems job to provide that to the applications at deployment/provisioning time, even if it has to generate yaml-files from it. And the source-of-truth shall be version-control.
3. Some applications may benefit from being able to fetch "configuration" at runtime - but is it really configuration then and not a missing abstraction/service in the architecture?
4. Feature flags and stuff like that should be pushed to the deployment/provisioning system that then provides it to the applications. Whether that is via API, config-files, env-vars, hot-reload, or restarts is context-dependent.
5. Application system-configuration (think tomcat server.xml) shall have a optimized default built-in production-safe in the package and any values that could be changed shall be provided to the application by any of the means mentioned above.

I would love to hear what your thoughts is around this?

One thing I like to think about with caches is to think of an "ideal" refresh rate and an "acceptable" one. We try to refresh at the ideal rate, but things don't actually start to break down until we go past the acceptable one. For example, when we had an ecommerce site that had to deal with exchange rates, we would update daily, but it was considered acceptable to use values up to 7 days old.

Let me see if I got it, imagine that there is one microservice (A) that consumes data from other 10 microservices (B, C, D...) . In this case there would be 9 different caches in the context of microservice A? Is that?

What about having one or several services or DBs involved in, let's say, customer information? Might that be a scenario when you should not should not share or replicate data across consuming services? I would think that some data is better fetched on demand if the costs is low.

Nice information.

Having one scenario in my project like promotion, tax computation during invoice. In this I’m having dependency with product, price, customer info, promotion definition, inventory,tax info etc.

Keeping all in cache is best if some reference data huge ? Your view please