Here some of the most seen pitalls are listened

"I do it with some kind of rpc". Wrong. I have often seen programmers taking their favorite framework around their programming language like WebApi etcetera and started. I give you some reaons why you should rely on a messaging backbone:

It is just a question of time until you run into scheduled functionality
It is just a question of time until you run into long running processing functionality
It is just a question of time until you have to synchronize data between your micro services ("eventual consistency")
It is just a question of time until you recognize you would have done better with some kind of decoupling the client from
the server in asynchronous operation scenarios
It is just a question of time until you realize all in all that your micro service should run inside its own 24 hours available process
It is just a question of time until you need some kind of load balancing
It is just a question of time until your asynchronous data must be preserved - even in case of software failure
It is just a question of time until your asynchronous data must be delivered to various micro-services

Some fundamental issues before giving further explanations to the points above.

A micro service is one deployment unit
A web server is here for response/reply communication style around http/https
Lots of functionality can happen in an asynchronous style (do not mix with non-blocking client calls!)
Load balancing should work in a homogenous way for remote procedure calls as for asynchronous operations
Guaranteeing the preservation of data can a challenging task for a self-written implementation (you also need a way to re-deliver the data to your micro-services afterwards)
The event "OrderCreated" is most probably interesting for the following micro-services: Accounting-service, Inventory-service, Confirmation-service etcetera. Typically delivered in an asynchronous way

The explanations

A micro service is one deployment unit
If you run within a webserver context and face 1 - you will start with the deployment explosion. Reason: You will most probably program some kind of service (windows service or whatever). So you got to deploy your webserver specific artefacts as well as for you scheduler.

A web server is here for response/reply communication style around http/https
If you start doing long running operations in a web server you are really on the wrong track. Probably you realized it and wrote your own process host like a windows service or whatever. You have already hurt the principal with the deployment units.

Lots of functionality can happen in an asynchronous style

Surprisingly a lot of programmers - and business representatives - live in a synchronous world. "If I press the button the order must be placed in the same moment the stock must be reduced, the confirmation be sent, and the postings for the bookkeeping department be done". I tell you: Forget it. We talk here generally about some milliseconds. The only hot issue could be the stock number. Even here the situation must be analysed. If you start doing all synchronously you loose several advantages: Performance and decoupling.

Your business grows - load balancing

Imagine you have decided to break the rule "one micro-service is one deployment unit" and broke off your micro-service into a webserver based rpc (WebApi or whatever) and for long running processes into a self-written daemon with its own process and threads. Now you got to load balance both of them. For your rpc you will go for a standard webserver load-balancing. For your daemon things get more complicated. You will start to implement some kind of round-robin load-balancing for this part. And this can end up in quiet a challenge (machine-wide load-balancing, threading etcetera).

Your most valuable asset got lost: Data

Rpc is less problematic as it couples the client to the server. If somethings goes wrong the caller will notice it as he awaits data from the server. The application code is responsible to handle this adequately. It gets more complicated with asynchronous data. You need some kind of acknowledge mechanism for the data dispatcher and the data consumer. The consumer must signal to the dispatcher the correct handling of the data or - in case of failure - to signal the dispatcher not to delete the data. In the later case the dispatcher must re-deliver the data as soon the problem was fixed in the consumer. This implies some kind of storage for the data that must be re-delivered at a later point in time.

Routing

Your asynchronous data must be routed to different micro-services. This mechanism must be implemented in a loose coupled way. It must be easy to register a new micro-service for events.

Solution

All of these issues can be solved with the help of a messaging infrastructure.