Potential issues with poll frequency restrictions at scale

Tech Talk
1

In developing the Woocomerce plugin, I realized that there could be some potential problems with the once-per-second frequency restriction of polling ETN’s servers for payment confirmation as mentioned in the API guide. This is true for web-based stores in particular, and especially for large-scale projects like e-commerce stores that have several payments processing simultaneously at any given time.

Let’s say the seller implements a feature that continually checks in the background for payment confirmation on the payment page so that the page can update automatically upon payment. Let’s say he checks this once per second. This would be fine for one order running at a time, but multiple orders running concurrently would exceed one request per second.

An obvious solution here would be to increase the timing between AJAX updates to, say, 3 seconds. This would detract a little from the “instantaneousness”, but moreover, if two different orders were started within microseconds from one another, you would still end up firing 2 requests within a second. Perhaps the seller could integrate a background check that records the timestamp of the last poll and makes sure the next poll only fires one second later, though this would increase development complexity somewhat

The correct way would most likely be to implement the webhook and have it process the payment directly. Then have the front-end AJAX poll your local database (instead of the ETN API) every second to check for order completion. This is how the Woocommerce plugin currently works, with some fallbacks to poll once per page reload if the web developer neglects to insert the correct callback URL on Electroneum’s vendor page.

At this stage, this issue is most likely not a problem at all, given the early stage of the beta. But I’m just putting it out there to start the conversation and get some ideas on how large-scale installations can handle this.

Any suggestions on how the frequency restrictions can be lifted, but with some checks in place to prevent DDOS or spamming? Some solutions I could think of are:

  • Allow more than one request per second, but impose a once-per-second limit on polls that have the same payment ID.
  • Have big players apply for lifted restrictions and consider them on a case-by-case basis.
2

Hi Ben,

Thanks for the feedback and suggestions.

We won’t comment on how our anti-spam system works across our platforms beyond what information we have previously made public.

However, I shall clarify that the “once per second” limit on the poll is per transaction, not per account. If you are a supermarket that has one account with hundreds of stores each running dozens of POS terminals, then each terminal can poll once per second (i.e. many simultaneously).

We will always reach out to our vendors should this limit be breached before taking further action so you should not fear this limit, just respect it :slight_smile:

Using the webhook avoids this issue and offers a faster notification of payment, so this is always our preferred method.

I will ensure the API Guide’s next update clarifies this.

Egg

6 Likes
3

Hi Egg,
This is great! Yes it needs to be in the API guide.
Thank you!

1 Like
4

Oh, you’ve done it already :+1:—quick again! ; )
And this is “reassuring”:

So yes, the way forward remains the webhook!!

1 Like
5

Thanks for the speedy reply and clarification. You guys are always thinking of things like this long before we do… :grinning:

1 Like
6

Please keep all the feedback coming! Having you all implementing the API will definitely bring thing up we’ve not thought of, but I’m sure we can help resolve them as they come up :slight_smile:

Egg

1 Like