I die a little inside every time we use the words "upstream" or "downstream", because they mean completely opposite things if you're talking about the network layer vs. the application layer. One of the many ways technology knowledge silos are kept in place.
1
1
Most network designs refer to "upstream" as the flow of traffic "towards the core", or "towards the internet". But in load balancing and proxying, "upstream" means the flow of traffic "towards the backend servers", or "towards the edge".
1
1
Of course, once you're on the origin server on the edge of your network, the terms flip back again, and that NGINX server that load balanced you is considered an "upstream server".
1
A related issue occurs when talking about north-south vs. east-west traffic. The traffic from your edge server actually always has to go "north" (upstream) before going "east" or "west". How far north depends on your network design.
1
I'm not a networking specialist by trade but I've been working with them since I was a kid in the 1980s beginning with my 300 baud modem BBS, followed by hacking X.25 networks... and this stuff isn't necessarily that hard, it's all one big historical-contextual jargon tangle.
1
1
Replying to @svrc
Are you aware domain-driven design uses the terms to refer to one team’s (or context’s) dependence on another team’s changes? Fun.

Aug 26, 2020 · 8:29 PM UTC

1
1
Replying to @stilkov
Ah yes! And then there's Github remotes and pull requests. Those at least I don't think are too overloaded, I mean origin vs. upstream sort of makes sense, unless you're dealing with lateral forks? English is "fun".
1