Hacker News Reader

> It's actually quite common for exchanges to offer discounts/rebates to firms that trade more

I reworded a bit to give a better idea of what I meant. In general there are bulk discounts but there's always some form of "QoS". Either you get throttled above a ceiling, or you pay through the nose to have that ceiling higher for yourself and have everyone else throttled.

All tiered systems work like this. The fixed price goes up and gives you access to better service, higher limits, lower price per usage, etc. As long as you don't have virtually unlimited capacity you can't treat your system as if you do.

Mobile operators have to do the same. They charge a base contract price that sets the tier, then charge per usage within that tier, give different ceilings, QoS priorities, and throttling rates. And no matter how big you are as a customer at some point you either pay a surcharge or get throttled so the system stays up and other customers are also served. (source: I worked both for a large telco, and for a customer that payed ~3million E per month to get the consumption costs for min/MB down to almost 0).

> I don't know why people always suggest solutions like this when it comes to exchanges.

By any chance do the suggestions always come after the exchange was down due to high transaction volumes? Sure, they could implement unlimited capacity. But since this is a tad unrealistic and actually crashing the system is worse than limiting to keep it just below crashing, perhaps the suggestion makes sense.

There aren't many sectors that I can think of which give you "unlimited usage no matter what". There's "rate limiting" even in hospitals, where lives are at stake.

>By any chance does the suggestion come after the exchange was down due to the high volume? Sure, they could have unlimited capacity. But since this is a tad unrealistic and actually crashing the system is worse than limiting to keep it just below crashing, perhaps the suggestion makes sense.

I don't see a problem with rate limiting in general, if it's applied fairly. Good design should already entail that (it shouldn't be possible for customers to "crash" an exchange any more than it's possible for them to crash google.com). And many exchanges in fact have something like you described (customers can pay to buy more transactions-per-second capacity). But I don't think referring to customers as abusers or applying punitive fines is the right approach; if the exchange API let the customers crash it, that's the exchange's problem, and the customers shouldn't be blamed for taking advantage of whatever rate limit the exchange gave them (even if it gave them too much for its system to handle).

FWIW, eurex and xetra do have rate limits and will throttle and disconnect abusers.

There are also limits on average order to trade ratios (this is required by MIFID2 IIRC).

You’re right - the requirement on order/trade ratios is more a policy requirement, but venues are required to have limits to control excessive message rates.

Lots of exchanges have rate limits and messaging fees. And even if they don't, if you cause problems they'll shut you off.

To be fair, executions ("customer purchases") are relatively rare events. If we want to keep with the analogy e-commerce, you can think of orders/cancels as merchants repricing their wares and changing their on-offer quotas hundreds of times per second. Each. As a marketplace owner you probably would want to at least rate-limit that.

In a physical store you wouldn't get to the shelves from the throng of clerks running around with sticker guns.

> If AWS goes down during the world's biggest shopping day, we don't blame the customers, we blame Amazon.

Yes. We do. But the customers blame us. It may not be our fault, but it's still our problem.

Do you know how Amazon stays up during Black Friday? Rate limiting.