Where TLS ends
Somewhere in your architecture TLS has to end, and choosing where is a real design decision.
End it at the edge, as most people do. Your load balancer holds the certificate, decrypts, and forwards plain HTTP to your application servers.
You get one place to manage certificates and ciphers, the cryptography concentrated in one tier, and the ability to route on headers. What you paid for that convenience is an assumption: that the network behind your balancer is trustworthy.
The assumption that broke
Watch that assumption take a public beating. In 2013 leaked documents showed an intelligence agency tapping the private fibre between one company's data centres, where traffic ran unencrypted precisely because it was internal.
Adopt the response the industry landed on: treat your own network as hostile too. In practice that means encrypting again from your balancer to your backends. Or going further with mutual TLS, where both sides present certificates so a service can prove which service is calling it.
Expect distributing those certificates yourself to be painful. That is a large part of why service meshes exist. They put a proxy next to each of your services and transparently upgrade the traffic between them, rotating keys automatically.
Keep two edge details ready. A strict transport header tells browsers never to use plain HTTP for your domain again. That closes the window where a first unencrypted request gets intercepted before your redirect fires, and a preload list bakes it into browsers before anyone has even visited.
Drop the performance objection, because it died long ago. When one large mail provider went encryption-only in 2010, it cost them under 1 percent of their processors and under 2 percent of network overhead, on 2010 hardware. If TLS shows up in your profiles today, something else is wrong.
Worked example
In October 2013 the Washington Post published an NSA slide describing the MUSCULAR program, complete with a hand-drawn smiley face next to the note "SSL added and removed here," marking the exact point where Google traffic crossed between data centers in the clear. Google engineers responded publicly and angrily, and the company accelerated a program already underway to encrypt all inter-datacenter links, finishing within months. It later published details of ALTS, its internal mutual authentication protocol, under which every RPC between internal services is authenticated and encrypted by default. That one slide did more for internal-traffic encryption than a decade of conference talks: within two years, encrypting east-west traffic went from paranoia to a checklist item, and today a service mesh gives a ten-person startup the posture Google had to build by hand.