[buran77]

Usually what works for such abuses is either to charge extra (tiers depending on volume) to discourage abuse or at lest to cover losses, or throttling the biggest offenders when getting unreasonable peaks in order to keep the system always running.

Both are used in many other sectors. If you have "industrial level" needs you usually have to pay extra either for the service or for additional infrastructure needed to provide you that service, or you simply get everything throttled to sustainable level (think water, electricity, etc). Most traders would not see any difference and the ones that would will have to think twice before DoSing.

[logicchains]

>They could put tiered charging and above a certain volume of transactions apply an additional fee (one time or per transaction). This is a model used in many other sectors.

It's actually quite common for exchanges to offer discounts/rebates to firms that trade more, because these firms are essentially providing a service to the exchange (market making, and generating turnover). Much like how other industries offer discounts for buying in bulk.

>The other option is to rate limit the biggest offenders when the system's performance limit is reached.

I don't know why people always suggest solutions like this when it comes to exchanges. If it was an e-commerce service and somebody suggested "let's rate limit customers to reduce load", it's be shot down as a lazy solution (and a great way to lose customers). If a platform isn't good enough to support the load its customers place on it, then it needs to be improved. If AWS goes down during the world's biggest shopping day, we don't blame the customers, we blame Amazon.

[buran77]

> 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.

[logicchains]

>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).

[gpderetta]

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).

[andylynch]

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.

[evanpw]

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

[bostik]

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.

[gowld]

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