Sure, the initial login itself has to be done at the origin, or connect to a database, but token authentication can be done at the edge. That means that if, for

Sure, the initial login itself has to be done at the origin, or connect to a database, but token authentication can be done at the edge. That means that if, for example, users have to pay for articles, you can still cache the article because the authentication can be validated at the edge. There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here. In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.