Here's an additional bit of info you might find interesting. I've been keeping an eye and developing a bit with their API and noticed a change that appears to be correlated with their attempts to fix server load. The listings.json file recently had a trim to the data it was sending. It previously contained completed order data that still is in available in listing.json. listings.json would previously send back completed order data for 25 cards at a time but that went away.
I actually have a backup of the file from when I was working on it. Here's an example of listings.json from 4/21. Compare that with the file sent back today.
I think you are right with some of your assumptions and this issue appears to be at the architecture level. Although I'm not so sure this is a load balancing issue as your were insinuating but rather a database/worker one. I think this was also evidenced directly at launch. Users were canceling orders and not receiving credit back for the cancelations. This isn't simply an issue of too many get requests or straight bandwidth at nodes. Database and worker load would be my bet to point the finger. Take what I say with a grain of salt. I have a fairly base level understanding of how the stack interacts without specific intimate detail at any layer. I think there is enough evidence though that I can, with some level of confidence, point there.
I don't know how you fix that issue though without simply waiting for or forcing the volume to decrease. It's not like they are going to have the ability to make the architectural changes needed on the fly in the production environment in a short period of time.
You are correct however that this isn't a "game server" issue. The game and online connection, once the connection is made and data is synchronized, works flawlessly.