Letting every client hit all four of Furrow's services directly has an obvious problem: the subscriber mobile app, the farmer-facing web portal, and the read-only feed Furrow gives a couple of grocery co-ops that resell its boxes would each have to know about, authenticate against, and separately cope with the uptime of every one of those services. Rate limiting and authentication are really concerns about the outside world reaching Furrow at all, not concerns that belong to any single service — leave them unaddressed at the edge and every one of the four ends up reimplementing its own version.
An API gateway answers this by standing between clients and the fleet as the one address anything external ever talks to — it authenticates the request, enforces the rate limit, and forwards it to whichever internal service actually owns that URL, sometimes folding calls to several backend services into a single response so a client isn't paying for multiple round trips just to render one screen.
A more targeted version of the same idea is Backend-for-Frontend (BFF): instead of one generic gateway trying to serve every client equally well, each distinct client gets its own tailored layer shaped around exactly what it needs. Furrow's mobile app screen for "your next box" needs the order status, the harvest contents, and the delivery window in one call — three backend lookups the general-purpose gateway would otherwise make the phone request separately, burning battery and time over what's sometimes a spotty connection at a farmers' market. The farmer portal's BFF looks nothing like it, because farmers need almost none of that and instead need their own upload history and payout totals, shaped for a completely different job.