I've been reading about microservices and event sourcing and how it decouples services from one another. There are 2 concepts I am not clear on. First, if in a microservices architecture, each service can be developed independently how do we account for inter-service communication dependencies ?
For example, if Service A and Service B need to communicate, A needs to send an event to a central bus which B needs to listen for and act upon, but this seems to create a lot of dependencies. Now, if I am developing Service B, i need to know all of the events that Service A can generate. Also, if service A adds any new event, Service B also needs to change in order to handle that new event. All of this seems to create a dependency nightmare, and seems like you cannot truly develop each service 'independently'.
Secondly, how is a request/response type scenario handled at the API gateway or process manager level ? If the top level request fires off a bunch of cascading or interdependent events which need to be handled before returning a response to the caller, is this a scenario suited well for microservices ?
Event sourcing is not event-driven architecture. Theoretically, you can have an internally event sourced Bounded Context/microservice in an ecosystem that doesn't use events for integration. You can also have non-event sourced BC's integrating via events.
Event-driven is one kind of asynchronous microservice integration. Synchronous integration is also possible. I don't know if that's what you implicitly contrast event-based integration with in your question, but the kind of dependency you have to manage is very similar in both cases.
So, no dependency nightmare that I can think of, at least no more than what you typically have when a subsystem A depends on a subsystem B.
Now, if I am developing Service B, i need to know all of the events that Service A can generate
No, you only subscribe to the ones you're interested in.
Also, if service A adds any new event, Service B also needs to change in order to handle that new event.
Again, not if you're not interested in it.
All of this seems to create a dependency nightmare, and seems like you cannot truly develop each service 'independently'.
As soon as one service depends on another, you obviously can't develop each service independently. You might have overinterpreted the kind of "independence" that loose coupling via events allows.