By day I am a slightly eccentric principal engineer living that remote life and by night a father, husband and ... slightly eccentric software developer.
In terms of inter-service communication I don't believe that it is an either/or scenario rather it is dependant on the use case you find yourself in. In my experience the rules of thumb I've used are:
If the data from the other microservice is required to complete the transaction then you should go for the synchronous communication method otherwise go for asynchronous.
Go for the method of least coupling first which is usually asynchronous messaging.
In the case of the data being required to complete the transaction some thought should be given as to whether these should be seperate services while it is not always the case it can be a smell that you may have gone too fine grained on your service separation and it is just something to weary of.
When it comes to sharing data across services I echo other commenters that you should avoid your services sharing a database. Aside from that how you share data across your services depends on your performance profile the options I've seen used are (in order of increasing complexity & performance):
Querying the other services API when needed.
Querying the other services API and caching the result as needed.
Building up a cache of the data in the services datastore populated by events emitted by the other service (in an event driven system).
Again the rule of thumb that I go by is start by going for the least complex and do some performance testing only moving onto the next option when your performance dictates that it's necessary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In terms of inter-service communication I don't believe that it is an either/or scenario rather it is dependant on the use case you find yourself in. In my experience the rules of thumb I've used are:
In the case of the data being required to complete the transaction some thought should be given as to whether these should be seperate services while it is not always the case it can be a smell that you may have gone too fine grained on your service separation and it is just something to weary of.
When it comes to sharing data across services I echo other commenters that you should avoid your services sharing a database. Aside from that how you share data across your services depends on your performance profile the options I've seen used are (in order of increasing complexity & performance):
Again the rule of thumb that I go by is start by going for the least complex and do some performance testing only moving onto the next option when your performance dictates that it's necessary.