An upstream context will influence the downstream counterpart while the opposite might not be true.
For instance, imagine there are two micro-services as bounded contexts, MoneyTransferService along with NotificationService. If money is transferred, notification should send an email, which includes some info related the transaction, to the customer. So
MoneyTransferService is upstream
NotificationService is downstream
DDD describes several organizational patterns that help us describe and/or manage the way different contexts interact. The most suitable pattern here is called Anti-Corruption Layer (ACL).
In order to follow this pattern in my example, to communicate with two micro-services, Repository layer could be used or a better solution is publish messages and consume them by tools like RabbitMQ. By using RabbitMQ, these services is just dependent on the message type, no need to know anything else.
As far as dependency is concerned, interaction between bounded contexts doesn't mean having dependency between them and you don't necessarily need to redesign them as a bounded context.
Your goal should be to get to the most meaningful separation guided by your domain knowledge. The emphasis isn't on the size, but instead on business capabilities. In addition, if there's clear cohesion needed for a certain area of the application based on a high number of dependencies, that indicates the need for a single bounded context, too.
There is nothing wrong with communications between bounded contexts which need each other to complete their business operations.
