I know the fundamental different between event based vs request based/driven architecture. Question is if the Request-based always done in synchronously while the Event-based is always done in asynchronously ?
Also, in API world (request-response), you normally return 400 http code for if the request message is invalid. And fortunately, in API world we can perform contract testing making the integration to be more robust.
What would be the best way to handle this similar issue in the messaging queue other than putting the message in the error queue ? is it the responsibility of the pubsliher service or consumer service to get notified first of the problem ?
Q1
That's the fundamental difference. The event publisher doesn't care who consumes it. In req/response services are tied up.
Q2
In event driven system it's responsibility of publisher to include everything that other services can use. In case the event doesn't contain everything that it needs then you can't publish event at the first place so you need to make sure that's the case. This is whole point of event driven since consumer expects to pick the message with all the data it needs.
If you still are able to publish the event that wasn't well formatted then you would reject the event and definitely log it . If that rejected event was part of transaction and linked to publish of another event then you would raise the failed processing event (Saga Pattern).
The best practice is to raise event with all the necessary payload. If events are not well formatted then It's a bad design and will eventually get complicated to handle at large scale.