The “stream” is a flow of ownership or authority. If you clone a remote git repo to your machine, your copy is downstream of the remote, and the remote is upstream of your local copy. The upstream is where you get the information from, e.g. when doing `git fetch`. Like when you get water from a river, the water you get comes from “upstream”.
Whenever you do a complex task you generally have to start somewhere and take a number of steps to get to the finished product right? Well, the first task you did is “upstream” of the second task and the third task is “downstream” of the second. In short, it’s just a way of saying one task comes before or after another task.
When you are downstream you depend on things that are upstream.
If you paint a house you depend on who provides paint. They are upstream.
The home owner you are painting the house for is downstream from you.
They depend on you to finish painting so they can sell their house.
So indirectly the home owner depends on the paint provider through you.
This can be applied in many ways in software but the idea is generally the same.
Depends on the context.
Usually upstream means a *dependent* (someone who depends on you), and downstream means a *dependency* (someone you depend on).
So say you have a storefront, and the frontend talks to a generic “store” service, which calls various dependencies like an identity service (for authn / authz), a payment processor service (e.g., Stripe), and these in turn all have their own dependencies.
If you trace the flow of traffic, starting from the source, you can draw a directed graph:
“`
┌──►Identity──►User DB
│
│
Store─├──►Items DB
│
│
└──►Stripe──►Other Deps…
“`
Follow the flow of traffic, as though it were the flow of a river, and you can see who lies downstream from whom, and who is upstream of whom.
In this particular flow, we say Stripe is downstream from Store Service, and the Store Service is upstream of Identity Service.
Latest Answers