For a system that consist of multiple services calling each other (e.g. Front End -> Backend -> Storage), I often heard people using terminology such as "downstream" or "upstream" services. I'm not clear which direction these mean. Data flows in both direction. Requests flow from more user-facing to more backend service, but responses flow in the opposite direction, so it seems to me one either way can be argued
The downstream services are the ones that consume the upstream service. In particular, they depend on the upstream service. So the front-end is downstream to the back-end because it depends on the back-end. The back-end can exist meaningfully without the front-end, but the front-end doesn't make sense without the back-end.
The dependency doesn't have to be as strong as I made it out to be in the previous paragraph. More generally, upstream services don't need to know or care about the existence of downstream services. Downstream services care about the existence of upstream services, even if they only optionally consume them.
Unfortunately there are differences in opinion on the meaning of upstream/downstream. When talking about system architecture, I define it as follows:
Given a system of concern, systems that initiate messages/data exchange to the system of concern are upstream systems, and systems that the system of concern depends on (i.e. those to which my system initiates data exchange) are downstream systems.
This link from ibm describing interactions with one of their products corroborates this view: Integrating with upstream and downstream systems
An upstream system is any system that sends data to the Collaboration Server system. A downstream system is a system that receives data from the Collaboration Server system.
Given the terminology 'upstream' and 'downstream' it may help to make an analogy with a river. If you drop a message (data) in the river it flows from upstream (initiator) to downstream (receiver).
Anecdotally, I've found that architects and middleware developers use this definition and web developers the opposite (maybe due to 'upload'ing).
With Event timelines, an event is upstream when it happens before a point on the timeline (i.e. triggers another event) and downstream when it happens afterwards (i.e. received the event). What is upstream and what is downstream in a sequence of events, therefore, depends on where you are in the timeline. An event can be both downstream and upstream, depending on whether your starting point is before or after it.
As @Jack notes RFC7230 tools.ietf.org/html/rfc7230#section-2.3 has this:
The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all
messages flow from upstream to downstream
The best way to think about this is to think of a river.
The downstream part of the river cant get any water unless it comes from upstream i.e. downstream is dependent on upstream for its water.
If someone destroyed the downstream part of the river, this would have no impact upstream. If someone destroyed the upstream part of the river, this would impact downstream i.e. it wouldnt get any water.
So downstream services depend on upstream services. If the upstream services are removed, the downstream services wont work properly.
This may be more a linguistic and geographical problem than a technical one.
The request for information goes upstream. It comes from a downstream system.
The response to the request for information (the requested information) goes downstream and is sent by an upstream system.
There is no difference between the classic IBM view and today's web community's use of the terms.
A service provider (server) will be located upstream compared to a service consumer and sends information downstream to the consumer.
A service consumer (client) will be located downstream compared to the service provider and sends requests upstream to the provider.
Theoretically roles of physical systems could change instantly and so would the direction of the stream between those systems. In a peer-to-peer network this may be the case.
The terms uploading and downloading are client centered terms. From the client's perspective a request is uploaded and a response is downloaded, which is consistent with the stream metaphor.