Fwiw there's a 290k sqft DC on Denny a few blocks from the Amazon towers https://h5datacenters.com/seattle-colocation.html
If you live in Seattle you've probably walked right past it. Small potatoes compared to a 10M sqft DC but it hosts real traffic.
On top of the architectural challenges and efficacy of it, you have to contend with the terms of the bank loans that apply. Those are why the buildings "can't" lower rents to attract new business.
If they sign a lease at a new lower rent it basically triggers a re-check of "can they repay the loan based on their rental income?", which comes back as "no". That trigger _doesn't_ occur if you just leave the building empty, with _no one_ paying rent, because your last mark to market rent was high enough.
Fundamentally changing the type of tenant in the building would presumably trigger that check as well.
It's a shell game that eventually leads to the loan defaulting, but both the bank and the building owner are happy to pretend they can't see the train coming down the tracks at them.
> If they sign a lease at a new lower rent it basically triggers a re-check of "can they repay the loan based on their rental income?", which comes back as "no". That trigger _doesn't_ occur if you just leave the building empty, with _no one_ paying rent, because your last mark to market rent was high enough.
Minimum DSCRs have long been used to monitor the current value of a property, and less income is less income.
> It's a shell game that eventually leads to the loan defaulting, but both the bank and the building owner are happy to pretend they can't see the train coming down the tracks at them.
This makes no sense. Why would a lender not want to keep tabs on their investment? What does shell game (a game where someone is intentionally deceived) even mean here?
Yep, the issue is that recalculating DSCR doesn't happen on the right timescale to incentivize reducing rents, instead incentivizing keeping vacancies open and using a pro forma DSCR.
The banks know this is a structural issue, but are likewise incentivized to keep "strong assets" on their balance sheet, rather than a bunch of troubled assets bound for default.
The claim isn't that they can keep this up forever, it just needs to last another quarter, every quarter.
The shell game is both parties knowing that the cups are all empty but still playing because it's better for them both to do so.
DSCR is calculated at least once per year. I don’t know what pro forma could mean here, it’s purely a cash flow calculation. The money came in, or it didn’t.
> The claim isn't that they can keep this up forever, it just needs to last another quarter, every quarter.
I don’t understand what this means, or what is being “played”, the lenders all have a near real time view into the business. The lack of cash flow can’t be papered over without engaging in fraud, but it’s also up to the lender to decide if they want to take action due to a failing DSCR.
This comes across strongly any time you hear management talking about "fungibility of engineers". Everyone is a full stack everything engineer, and AI makes that even easier for them to trick themselves into believing.
If anything, I feel like AI has made domain expertise more important, not less, as the "confidently wrong" error case for agents has no one able to sanity check it. At least before AI a human would dip their toe in the water and usually realize that having no idea what they were doing, and not even being able to understand what the comments mean, was a sign that they need to go find someone more experienced to help.
Look, it wasn't _my_ request that made the server fall over, it must have been one of the other several thousand thoughtless scrapers running on the website that caused it to die.
If you're claiming that the operators of high volume AI scrapers that wantonly disregard rate limits and all common sense are unethical then I'm right there with you. But that's not at all what was described upthread nor is it the only way in which bots get used by any stretch of the imagination.
As far as anti-bot countermeasures go I quite like proof of work solutions since those disproportionately impact high volume scrapers without noticeably impeding a small hobby project.
Unfortunately the operators of many major websites appear to want something akin to DRM with the excuse of bots used merely as window dressing.
There was a time when a person could walk through a few department stores every week (or even every day) just to take note of some prices along the way, and ultimately tabulate them to try to identify and snatch up the best deal once it happens.
And if everyone did this, it'd be a real problem. The stores would be clogged up by geeks writing notes in little books with Parker Jotters and just basically wasting space and taking up air conditioning while they sleuth out the best way to put the screws to the company for a few measly dollars.
That'd be awful.
But not many people ever did that in stores, and not many individual people are doing that today with the web. It's really not a problem.
(And if a website in 2026 can't stand the burn of several thousand personal scrapers that are operated by people who actually want to buy stuff from it, then maybe that system simply sucks and needs to be rethought.)
> There was a time when a person could walk through a few department stores every week (or even every day) just to take note of some prices along the way, and ultimately tabulate them to try to identify and snatch up the best deal once it happens.
This is how it started! I noticed certain things during my weekly shop that I did a double-take on and thought "wasn't that $cheaper last week!?". Took me ~ 45 min to figure out that the retailer actually has a really nice graphQL endpoint that powers the "view your previous receipts" function on their website. Of course they don't document this / make it available for 3rd parties... so scrape it is!
I wrote a bot to dump every receipt into a sqlite DB and I fire it up ~ weekly to pull down receipts that it doesn't have locally.
Turns out, not _everything_ has gotten more expensive @ my local grocery store over the past few years... just most things have :/.
> But not many people ever did that in stores,
There's a cottage-industry of firms out there that get gig-workers to pop in to $randomStore and take a picture of $randomItem on shelf w/ the price tag in the photo. The firms sell this info to stores that want to know how a competitor might be doing pricing / placing certain items on the more valuable shelf spots.
> and not many individual people are doing that today with the web. It's really not a problem.
That's my point! I scrape a few hundred pages per day across _many_ domains. My bots respect 429s and they have some other backoff/random-jitter strategies baked in to _not_ be the reason anti-scrape proliferates.
Please accept all possible encouragement. This is exactly the kind of personal project that a world wide web of network-connected computers is supposed to enable.
(I have no idea how it is that so many of us here have come to lose the plot.)
Microsoft.com is also owned by the marketing org, not the engineering org, for various reasons that predate the existence of many employees at Microsoft now.
This is why with rare, rare exceptions nothing "real" is on Microsoft.com including even the login page, with one exception (the passkey domain).
Not quite. At least the one I found is some trickle down economics myth.
The one op is referencing is more like the dollar is used to pay off the waitstaff, who pay their rent to the landlord, who pay their over due taxes, so that the government can issue a refund to the cafe owner. The dollar ends up back in the hands of the cafe owner, who puts it back down on the table with all the debts paid off.
It definitely looks like the old tale come true - at Microsoft people would warn against using Google because then Google could figure out what we're working on, since it was pretty easy to tell where a query was coming from.
Sounded far fetched back then, and on the face of it illegal, but now it's just common sense I imagine.
It's pretty clear to me that these systems have a massive potential for intelligence agencies as people move more and more of their internal thought process to an external tool.
And, of course, intelligence agencies are good at realizing potential.
That's the success case.
In the failure case you have emboldened, pressured teams jumping in to make a "quick fix" or "that feature we needed" in a codebase for a team they've never heard of, and leaders cheering it on in the name of progress.
Not every company is going to see those boundaries and stakeholders as features, and they'll be under pressure to "mitigate those blockers to execution". That's where the cognitive debt skyrockets.
I have no idea how you read a statement about how nazis and flame baiters should be able to speak their mind and then concluded that the author only cares about some minorities.
Given that the author didn't say any of the things you claimed, and indeed said the opposite, it leads one to conclude you have a problem with the example used.
Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?
Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.
>Is there some obvious reason not to measure requests per minute rather than second?
It's much less obtuse to say something like "average req/min" or whatever, but then again you can't write a cool blog post about misusing an SI unit for radioactivity and shoving it into a nonsensical context.
In my experience, rate limits are more often per second. It's easy to talk about kilo or mega-units, so this isn't as big an issue as the awkwardness of talking about very very low volume services. Maybe those (generally) inherently don't care about rates as much?
In my perception there is a difference between 1req/s as a rate limit, and 60/min. The difference has to do with bucketing. If we agree that the rate limit is 1/s, I expect to be able to exactly that and sometimes 2 within the same second. However, if we agree on 60/min, then it should be fine to spend all 60 in the first second of a minute, or averaged out, or some other distribution.
This also helps with the question I always get when discussing rate limits “but what about bursts?”. 60/min already conveyed you are okay to receive bursts of 60 at once, in contrast to with 1/s.
In my experience it is exactly the low rate service that care about rate limits as they are the most likely to break under higher load. Services that already handle 100k req/s typically don’t sweat it with a couple extra once in a while.
An effective rate limiting system has multiple bases in my experience, depending on what the goal is. But I usually implement the configuration as a list where you can define how much requests are allow maximum per how many units of time.
E.g. to prevent fast bursts you limit it to 1 request per 1 second, but to avoid someone sending out 86400 requests a day you also cap them at 100 per 86400 seconds (24 hours) and 1000 per 3600 seconds (1 hour).
Whichever limit they hit first will stop it. That isn't hard to implement if you know how to deal with arrays and it allows long term abuse, while still along fast retries if something went wrong.
I guess there's a difference between talking about how many requests a system is capable of handling, and how many they actually get.
At least when i encountered the discussion initially (some thirty years ago) I'd say we usually talked about how many requests the system was capable of handling. Then requests per second was the obvious unit since a request usually took less than a second to process (obviously depending on the system and so on - but mostly), so using that unit often gave a fairly low, comprehensible number.
Was it ten? A hundred (very impressive)? Perhaps even a thousand (very, very impressive!)?
Multiply those numbers by 60, and there's suddenly a lot more mental gymnastics involved. By 3600 and you're well into "all big numbers look the same" land.
reply