With any kind of proxy, forward or reverse, all network traffic is directed first to the proxy on its way between the client and server.
The behaviour you described is more akin to a peer-to-peer network with a centralized server to help peers find each other, which isn’t how Caddy operates.
In terms of performance, Caddy is plenty lightweight. Web servers themselves aren’t particularly resource-demanding, it’s the scale of the traffic and the type of service that really determines the resources required. Since it’s just a home server setup, your traffic, lets just go ahead and say you’ve got less than a hundred people accessing your server. Caddy will require very little overall resources.
Reverse proxying is also not very intensive at all unless you need responses to be buffered and operated on for some reason. For the most part, Caddy just accepts a request, puts it on hold while it shoots off another one to the backend, takes the response it gets, and finishes up the initial request by handing off the response. It doesn’t do much processing; it just acts as a middleman. With small numbers of traffic… You could probably do this on truly weak hardware. A quad-core with an entire gigabyte of RAM is plenty. I have a number of networking services (self-hosted Tailscale and Zerotier, Wireguard and OpenVPN, with Caddy serving control panels for these) all running on a single-core 512MB RAM VPS. You definitely don’t need new hardware just to run Caddy itself.
The only place you might be hurting is that 100Mbit Ethernet connection. The networking hardware handles almost all of the grunt work, but if you’re transferring large files or streaming media through this reverse proxy, this pipe might be a little tight. Especially if it’s serving over LAN or if your internet pipe is better than 100mbit.