2025 Black Friday / Cyber Monday: FLASH SALE & MEGATHREAD - "The Trade War"

Maki

@FAT32 said:

01/12 06:48

QDE: 9.95€/yr 1GB VPS in NL

• 1 vCPU
• 1GB RAM
• 15GB SSD (RAID-10)
• 2TB @ 1Gbps
• 1 IPv4 + /64 IPv6
• Location: Amsterdam
• Quantity: 40
• Coupon code: AJWLH67P53C1
• 9.95€/yr

---

Special Notes: Order remain for 30 mins, unpaid orders will be cancelled

Good deal

zejjnt

@jet3918 said:
The busy work has finally ended.

Ended for whom? ;D

Maki

@nghialele said:

@muffin said:
xue hua piao piao bei feng xiao xiao

ni hao，大哥，你怎么样？

sa˥.sa˥.ŋe.joː˥ŋe.joː˥ ! sa˥.sa˥.ŋe.joː˥ŋe.joː˥ !

Neoon

@doobydoe said:

brother, wdym, I am loosing a game over lost packages.

Zyra

@zejjnt said:

@jet3918 said:
The busy work has finally ended.

Ended for whom? ;D

For all of us, we are now allowed to drop work and go home. Results with HR may vary

zejjnt

@Maki said:

@nghialele said:

@muffin said:
xue hua piao piao bei feng xiao xiao

ni hao，大哥，你怎么样？

sa˥.sa˥sa˥.ŋe.joː˥ŋe.joː˥ ! sa˥.sa˥sa˥.ŋe.joː˥ŋe.joː˥ !

Kan ni skriva på fornnordiska istället tack på förhand MVH grannen

doobydoe

@Neoon said:

@doobydoe said:

brother, wdym, I am loosing a game over lost packages.

Must be skill issue

cainyxues

@doobydoe said:

that's why its better to be in IT

zejjnt

@Zyra said:

@zejjnt said:

@jet3918 said:
The busy work has finally ended.

Ended for whom? ;D

For all of us, we are now allowed to drop work and go home. Results with HR may vary

GLWP
(Good Luck With Purchases)

Maki

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@Maki said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@senos said:

@avsisp said:

@FAT32 said:

01/12 00:00

AVS ISP: 25€/yr 1TB SSD/NVME Unmetered Storage VPS in AL/UK(IE)

• 1 vCPU
• 1GB RAM
• 20GB NVMe (System) + 1TB SSD Storage
• Unmetered @ 100Mbps
• 1 IPv4 + /48 IPv6
• Location: Albania
• 25€/yr

• 1 vCPU
• 1GB RAM
• 1TB NVMe Storage
• Unmetered @ 1Gbps
• 1 IPv4 + /48 IPv6
• Location: UK with IPs Ireland Geo (IE)
• 25€/yr

---

Notes:

• PayPal Only (All BF deals must be paid via PayPal)
• Manual Setup: Setup is performed manually, usually within 1 hour (varies by time of purchase)
• No Reservations: Cancelling at checkout does not reserve your slot. Your spot is ecured only after PayPal payment completion
• Batch Processing: VPS servers are setup in batches. Account and VPS details will be emailed after setup is complete
• Final Sale: Stock is extremely limited. Once sold out, these deals will NOT return. Payments are final. No refunds on promotions.

Paid but it did not ask for account registration. What next?

We work on Albanian Time, we have just woken up for the day here.

We are checking the orders now and having some coffee - then we will process them.

There may have been a glitch - I'm seeing multiple orders for the same product here. Some may be refunded. Only the first one will be accepted. (multiple people had the payment page already up when the first paid and locked it, so all of them that were on PayPal already paid. Which isn't an issue - it just means we will have to refund some, we obviously can't honor 16 storage deals that large due to a glitch).

The first ones of each will receive an email from support {at} avsisp.com asking for which OS and the email address on your account (if different than paypal). The others will receive a prompt refund.

Apologies for any delays. Posts here on LET may not align with our operating hours, of course - which may lead to slight delays between post / order and us processing them.

Thank you for understanding.

So that means only two orders will actually go through? I really thought this was going to be the best deal I snagged for BF2025. Thanks for the generosity anyway, and huge congrats to the two lucky winners !

Yes, of course - they were intended to be limit 1 of each deal. But what happened was LET people have those fast fingers and multiple of you opened the page at the exact same time, proceeded to PayPal at the exact same time, and paid at the exact same time before one paid and locked the page. Down to the ms, they were within 2ms of eachother which is insanely fast on you guy's part (I love the enthusiasm! Thanks for the support!).

Refunds have already been issued. I think it's better we don't post publicly the emails of the 2 that were actually first, so I'll just say to check if you were refunded. If you got a refund, you weren't the first. If you didn't see a refund, you were first and you'll get a support email shortly with questions on OS and account email.

Apologies again for this glitch.

Too bad for them, need to wait for more than month to get their money back, because of faulty system to not recheck things

It isn't a faulty system. It's PayPal themselves. We relied on their system to handle that. So now PayPal is a faulty system? Makes sense.... For sure..

As for a month, that's entirely incorrect.
1) if you paid with PayPal balance, it's instantly back
2) if you paid with linked bank, it's just cancelled and never gets pulled - no money ever moves
3) if you paid with card, it's instant for USA Visa/MC usually and for other countries or card types it's 3 days max, usually in 24 hours or less.

Again, apologies, but we had no way to control this glitch. You guys are just too fast - this isn't the first time this has happened in LET history. It's happened with WHMCS using hosts, hostbill hosts, etc. payments make it through but product OOS and then payment cancelled or refunded. It's quiet a normal glitch and isn't one that can be solved unless you're a bank with the computer processing payments directly connected to your website which would be illegal but yeah - 2ms isn't enough time for notifications to cut transactions to come. And if you're already on the payment page, PayPal is going to accept that payment, even if the order page is already disabled. That's a PayPal issue - not one we can control. And again, with 2ms differences in payment times, I'm not sure any system in the world could have stopped that glitch regardless. Try to ping your own phone from your laptop in the same house or something some time. That's 2ms or more...

You shouldn't be relying on the payment provider to marshall who got the deal first. If someone has got to the stage where they've already been offered a deal and paid the advertised price, you should honour it.

If you only have one deal to sell, you should raise the invoice to whoever gets there first, and you can do that locally and ensure there is only one. If they don't pay the invoice in a reasonable timeframe, then cancel the order and restart the offer.

Again, that wouldn't have worked in this case. They were 2ms apart. They were at the page at the same time. There's no way it could have been prevented. PayPal themselves didn't stop it - on WHMCS with a limit 1 product even we've had this happen before. So what you're saying is incorrect and isn't compatible with how programming, APIs, internet latency, etc work.

We did the responsible thing and refunded them because we don't oversell our servers. We can't very-well sell 16TB of space when we can't guarantee that much space on the servers.

Apologies again to anyone refunded. But in the end, there was not other options for us but to handle it responsibly and give people their money back. We aren't some shady host that will oversell it rediculously to make a quick buck. We try to be responsible and not to oversell what we have available. If these had all been on Albania, it's possible we could have just added drives. But they were mostly for London - where we have less control to upgrade servers, especially without massive downtime.

Incorrect. They were on payment page at same time. Race condition wasn't possible to correct with 2ms differences.

You are naive, paypal job is to handle payment, not checking your stock

As "no way it could have been prevented", then you have problem with your stack, you didnt check if someone already click pay, you didnt check if someone already at paypal page, you didnt check if someone already have invoice in that product

So "Race condition wasn't possible to correct with 2ms differences." is also incorrect, you assume that the problem is the computational, or are you use old CPU for your server?

2ms, you say 2ms is impossible to correct, thats must be a joke, even in finance, such error is enormous

Also "They were on payment page at same time" this is your problem to let this happen, clearly not preparing the sudden visit.

You should read how to use single thread database, especially sqlite, it lock away shit when its updating, obviously will fix your "Race condition wasn't possible to correct with 2ms differences."

Read my last reply. We did indeed lockfile it. But everyone was on PayPal, not on our website. Our website page was locked. Anyone new coming to it got an out of stock. Those already at PayPal our system can't stop. PayPal link had a stock limit 1. I've already submitted a PayPal ticket to tell them what happened and ask them why their stock control on managed button links didn't work.

I have read, you are playing with yourself, lockfile in multithread, obviously will error

You take the shortcut and playing with people money instead

Here simple explanation on your "solution"

We have 3 teller, each will check the vault to tell customer its has gold in it before taking order, but to get to vault it need 1 minutes go and 1 minute back to check the gold

teller 1, on 01:00 check there is gold!
teller 2, on 01:01 take the gold!
teller 1, on 02:00 tell the customer there is a gold!

THATS THE PROBLEM

Instead of delegating the checking mechanism to 1 guy (single thread - 1 concurency table) to check the gold, you gamble that that time frame is enough to check the gold

Again, and this will be my last reply to this - we have a lot of work to tackle today....

There was multi-step limits and checks. The final one to fail was on PayPal, not at us. PayPal link had a strict stock limit of 1. PayPal still allowed 16 to go through. So yeah, sure, we could have paid 10k to a programmer to rewrite our entire stack to end up at the exact same situation regardless.

We did what we could. We refunded the ones that were oversold and that's all we could do. We've submitted a ticket to PayPal. There is nothing further we could or can do. So if all of your suggested ideas of how transactions within ms of each-other work - a multi-billion dollar company like PayPal you would think would have implemented them - but obviously didn't.

Apologies for the final time to anyone that was effected and got a refund.

It's fine if you don't want to reply again, but seriously actually read what we are saying.

Concurrency is a solved problem. It was a solved problem years ago. People were worrying about how to create reliable locking on filesystems 30+ years ago. This is exactly why the semantics of creating a symlink are like they are now. None of this is new or rocket science.

If you continue to believe that you did everything right, then you will have exactly the same problem in the future. And you will continue to incorrectly argue with everyone that you did everything you could.

But if you take the time to read what we are saying, and try to understand how the multiple suggestions given to you would actually solve the problem, then you could easily stop this problem from happening again. It just requires you to open your mind to the possibility that there are solutions to this problem that work.

For the final time - on our side it worked correctly. It was locked. Nobody new could order or get to the PayPal. They were ALREADY AT PAYPAL. PayPal link had a LIMIT OF 1 STOCK. PayPal allowed 16 to order what was limited to 1.

Do you see where this is going?

Concurrency isn't the issue. It's Apache with PHP. It's obviously concurrent regardless. You can't very-well limit a website to 1 visitor at a time - that's just insanity.

How this can be solved and will be in the future to avoid these issues - everyone must have an account to make an order, there'll be a delay added to when the PayPal forward happens with 3 checks first, and it'll be slow to get to PayPal to pay but won't happen again oversell like that.

So in the future, nobody will be able to order without an account. We tried it for these specials only to avoid people having to create accounts before they order, to streamline it. And this happened - so from now on, everything is locked inside our panel and nobody can order without an existing account. Problem solved.

Yeah just tell us how they can touch the paypal link in the first place, thats the "PROBLEM"

tfgp99

@itsTomHarper said:

@tfgp99 said:

@itsTomHarper said:

@itsTomHarper said:

£4 DEAL SLOT GIVEAWAY

Both @FAT32 and @mandala have put me in a dilemma with their generosity. As requested by both of them, let’s leave this to RNG then.

1 slot. If you’d like to snag this deal, just Thank this post. I’ll let RNG pick the person from the list of Thanks. (Fat and Mandala will be excluded )

Gotta head to sleep soon, so please be quick lads!

Context (for those who weren’t here):
https://lowendtalk.com/discussion/comment/4639159/#Comment_4639159

RESULT

RNG chose @tfgp99 as the winner! Congrats

Please place an order using the link below, I'll adjust the price to £4

https://my.veloxmedia.co.uk/index.php?rp=/store/black-friday-2025/let-flash-bf-2025-slc-ps4-year-deal-1

no way

Hi @tfgp99

I didn’t receive any PM from you yet. Please place an order using the above link (do not pay) and send me your invoice n.o. I’ll adjust the pricing.

Done sir!

doobydoe

@cainyxues said:

@doobydoe said:

that's why its better to be in IT

But AI wont take over drug dealer job.

zejjnt

@doobydoe said:

@cainyxues said:

@doobydoe said:

that's why its better to be in IT

But AI wont take over drug dealer job.

Not with that attitude it won't

tansel

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@Maki said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@senos said:

@avsisp said:

@FAT32 said:

01/12 00:00

AVS ISP: 25€/yr 1TB SSD/NVME Unmetered Storage VPS in AL/UK(IE)

• 1 vCPU
• 1GB RAM
• 20GB NVMe (System) + 1TB SSD Storage
• Unmetered @ 100Mbps
• 1 IPv4 + /48 IPv6
• Location: Albania
• 25€/yr

• 1 vCPU
• 1GB RAM
• 1TB NVMe Storage
• Unmetered @ 1Gbps
• 1 IPv4 + /48 IPv6
• Location: UK with IPs Ireland Geo (IE)
• 25€/yr

---

Notes:

• PayPal Only (All BF deals must be paid via PayPal)
• Manual Setup: Setup is performed manually, usually within 1 hour (varies by time of purchase)
• No Reservations: Cancelling at checkout does not reserve your slot. Your spot is ecured only after PayPal payment completion
• Batch Processing: VPS servers are setup in batches. Account and VPS details will be emailed after setup is complete
• Final Sale: Stock is extremely limited. Once sold out, these deals will NOT return. Payments are final. No refunds on promotions.

Paid but it did not ask for account registration. What next?

We work on Albanian Time, we have just woken up for the day here.

We are checking the orders now and having some coffee - then we will process them.

There may have been a glitch - I'm seeing multiple orders for the same product here. Some may be refunded. Only the first one will be accepted. (multiple people had the payment page already up when the first paid and locked it, so all of them that were on PayPal already paid. Which isn't an issue - it just means we will have to refund some, we obviously can't honor 16 storage deals that large due to a glitch).

The first ones of each will receive an email from support {at} avsisp.com asking for which OS and the email address on your account (if different than paypal). The others will receive a prompt refund.

Apologies for any delays. Posts here on LET may not align with our operating hours, of course - which may lead to slight delays between post / order and us processing them.

Thank you for understanding.

So that means only two orders will actually go through? I really thought this was going to be the best deal I snagged for BF2025. Thanks for the generosity anyway, and huge congrats to the two lucky winners !

Yes, of course - they were intended to be limit 1 of each deal. But what happened was LET people have those fast fingers and multiple of you opened the page at the exact same time, proceeded to PayPal at the exact same time, and paid at the exact same time before one paid and locked the page. Down to the ms, they were within 2ms of eachother which is insanely fast on you guy's part (I love the enthusiasm! Thanks for the support!).

Refunds have already been issued. I think it's better we don't post publicly the emails of the 2 that were actually first, so I'll just say to check if you were refunded. If you got a refund, you weren't the first. If you didn't see a refund, you were first and you'll get a support email shortly with questions on OS and account email.

Apologies again for this glitch.

Too bad for them, need to wait for more than month to get their money back, because of faulty system to not recheck things

It isn't a faulty system. It's PayPal themselves. We relied on their system to handle that. So now PayPal is a faulty system? Makes sense.... For sure..

As for a month, that's entirely incorrect.
1) if you paid with PayPal balance, it's instantly back
2) if you paid with linked bank, it's just cancelled and never gets pulled - no money ever moves
3) if you paid with card, it's instant for USA Visa/MC usually and for other countries or card types it's 3 days max, usually in 24 hours or less.

Again, apologies, but we had no way to control this glitch. You guys are just too fast - this isn't the first time this has happened in LET history. It's happened with WHMCS using hosts, hostbill hosts, etc. payments make it through but product OOS and then payment cancelled or refunded. It's quiet a normal glitch and isn't one that can be solved unless you're a bank with the computer processing payments directly connected to your website which would be illegal but yeah - 2ms isn't enough time for notifications to cut transactions to come. And if you're already on the payment page, PayPal is going to accept that payment, even if the order page is already disabled. That's a PayPal issue - not one we can control. And again, with 2ms differences in payment times, I'm not sure any system in the world could have stopped that glitch regardless. Try to ping your own phone from your laptop in the same house or something some time. That's 2ms or more...

You shouldn't be relying on the payment provider to marshall who got the deal first. If someone has got to the stage where they've already been offered a deal and paid the advertised price, you should honour it.

If you only have one deal to sell, you should raise the invoice to whoever gets there first, and you can do that locally and ensure there is only one. If they don't pay the invoice in a reasonable timeframe, then cancel the order and restart the offer.

Again, that wouldn't have worked in this case. They were 2ms apart. They were at the page at the same time. There's no way it could have been prevented. PayPal themselves didn't stop it - on WHMCS with a limit 1 product even we've had this happen before. So what you're saying is incorrect and isn't compatible with how programming, APIs, internet latency, etc work.

We did the responsible thing and refunded them because we don't oversell our servers. We can't very-well sell 16TB of space when we can't guarantee that much space on the servers.

Apologies again to anyone refunded. But in the end, there was not other options for us but to handle it responsibly and give people their money back. We aren't some shady host that will oversell it rediculously to make a quick buck. We try to be responsible and not to oversell what we have available. If these had all been on Albania, it's possible we could have just added drives. But they were mostly for London - where we have less control to upgrade servers, especially without massive downtime.

Incorrect. They were on payment page at same time. Race condition wasn't possible to correct with 2ms differences.

You are naive, paypal job is to handle payment, not checking your stock

As "no way it could have been prevented", then you have problem with your stack, you didnt check if someone already click pay, you didnt check if someone already at paypal page, you didnt check if someone already have invoice in that product

So "Race condition wasn't possible to correct with 2ms differences." is also incorrect, you assume that the problem is the computational, or are you use old CPU for your server?

2ms, you say 2ms is impossible to correct, thats must be a joke, even in finance, such error is enormous

Also "They were on payment page at same time" this is your problem to let this happen, clearly not preparing the sudden visit.

You should read how to use single thread database, especially sqlite, it lock away shit when its updating, obviously will fix your "Race condition wasn't possible to correct with 2ms differences."

Read my last reply. We did indeed lockfile it. But everyone was on PayPal, not on our website. Our website page was locked. Anyone new coming to it got an out of stock. Those already at PayPal our system can't stop. PayPal link had a stock limit 1. I've already submitted a PayPal ticket to tell them what happened and ask them why their stock control on managed button links didn't work.

I have read, you are playing with yourself, lockfile in multithread, obviously will error

You take the shortcut and playing with people money instead

Here simple explanation on your "solution"

We have 3 teller, each will check the vault to tell customer its has gold in it before taking order, but to get to vault it need 1 minutes go and 1 minute back to check the gold

teller 1, on 01:00 check there is gold!
teller 2, on 01:01 take the gold!
teller 1, on 02:00 tell the customer there is a gold!

THATS THE PROBLEM

Instead of delegating the checking mechanism to 1 guy (single thread - 1 concurency table) to check the gold, you gamble that that time frame is enough to check the gold

Again, and this will be my last reply to this - we have a lot of work to tackle today....

There was multi-step limits and checks. The final one to fail was on PayPal, not at us. PayPal link had a strict stock limit of 1. PayPal still allowed 16 to go through. So yeah, sure, we could have paid 10k to a programmer to rewrite our entire stack to end up at the exact same situation regardless.

We did what we could. We refunded the ones that were oversold and that's all we could do. We've submitted a ticket to PayPal. There is nothing further we could or can do. So if all of your suggested ideas of how transactions within ms of each-other work - a multi-billion dollar company like PayPal you would think would have implemented them - but obviously didn't.

Apologies for the final time to anyone that was effected and got a refund.

It's fine if you don't want to reply again, but seriously actually read what we are saying.

Concurrency is a solved problem. It was a solved problem years ago. People were worrying about how to create reliable locking on filesystems 30+ years ago. This is exactly why the semantics of creating a symlink are like they are now. None of this is new or rocket science.

If you continue to believe that you did everything right, then you will have exactly the same problem in the future. And you will continue to incorrectly argue with everyone that you did everything you could.

But if you take the time to read what we are saying, and try to understand how the multiple suggestions given to you would actually solve the problem, then you could easily stop this problem from happening again. It just requires you to open your mind to the possibility that there are solutions to this problem that work.

For the final time - on our side it worked correctly. It was locked. Nobody new could order or get to the PayPal. They were ALREADY AT PAYPAL. PayPal link had a LIMIT OF 1 STOCK. PayPal allowed 16 to order what was limited to 1.

Do you see where this is going?

Concurrency isn't the issue. It's Apache with PHP. It's obviously concurrent regardless. You can't very-well limit a website to 1 visitor at a time - that's just insanity.

How this can be solved and will be in the future to avoid these issues - everyone must have an account to make an order, there'll be a delay added to when the PayPal forward happens with 3 checks first, and it'll be slow to get to PayPal to pay but won't happen again oversell like that.

So in the future, nobody will be able to order without an account. We tried it for these specials only to avoid people having to create accounts before they order, to streamline it. And this happened - so from now on, everything is locked inside our panel and nobody can order without an existing account. Problem solved.

you’re right — inventory can’t be managed through PayPal. It has to be done through your account’s billing system.

jet3918

@zejjnt said:

@jet3918 said:
The busy work has finally ended.

Ended for whom? ;D

Actually, I just joined the BF party.

Hitori0221

who can sponsor this poor college student to pay for their gigahost bill?

https://www.nodeseek.com/post-527153-1

zejjnt

@jet3918 said:

@zejjnt said:

@jet3918 said:
The busy work has finally ended.

Ended for whom? ;D

Actually, I just joined the BF party.

more like wake but whalecum anyway

spaceowl

@FAT32 said:

@spaceowl said:

@FAT32 said:

01/12 06:24

SiteHub: $5/m 3TB HDD VPS + $15/m 10TB HDD VPS in US

$5/m 3TB HDD VPS

• 1 vCPU
• 2GB RAM
• 10GB SSD + 3TB HDD
• 9TB Bandwidth
• 1 IPv4 + /64 IPv6
• Location: Salt Lake City, US
• Quantity: 5
• Coupon code: BF-SHSTORE-FLYWG
• $5/m

$15/m 10TB HDD VPS

• 2 vCPU
• 4GB RAM
• 30GB SSD + 10TB HDD
• 30TB Bandwidth
• 1 IPv4 + /64 IPv6
• Location: Salt Lake City, US
• Quantity: 5
• Coupon code: BF-STOSHRE-RSLCB
• $15/m

Good. But why does it have to be in the US?

I dont even know where to start answering that question

I just mean that all the good storage deals this Black Friday are based in the US, except only one that I didn't see in time

Blembim

@FAT32 said:

• 2TB @ 1Gbps

Day 2 of begging for double bw🥺

LBF

Why are so many chinese people buying all these servers and stuff?

zejjnt

@spaceowl said:

@FAT32 said:

@spaceowl said:

@FAT32 said:

01/12 06:24

SiteHub: $5/m 3TB HDD VPS + $15/m 10TB HDD VPS in US

$5/m 3TB HDD VPS

• 1 vCPU
• 2GB RAM
• 10GB SSD + 3TB HDD
• 9TB Bandwidth
• 1 IPv4 + /64 IPv6
• Location: Salt Lake City, US
• Quantity: 5
• Coupon code: BF-SHSTORE-FLYWG
• $5/m

$15/m 10TB HDD VPS

• 2 vCPU
• 4GB RAM
• 30GB SSD + 10TB HDD
• 30TB Bandwidth
• 1 IPv4 + /64 IPv6
• Location: Salt Lake City, US
• Quantity: 5
• Coupon code: BF-STOSHRE-RSLCB
• $15/m

Good. But why does it have to be in the US?

I dont even know where to start answering that question

I just mean that all the good storage deals this Black Friday are based in the US, except only one that I didn't see in time

Hitori0221

@LBF said:
Why are so many chinese people buying all these servers and stuff?

Why are so many people buying all these servers and stuff?

Maki

@tansel said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@Maki said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@senos said:

@avsisp said:

@FAT32 said:

01/12 00:00

AVS ISP: 25€/yr 1TB SSD/NVME Unmetered Storage VPS in AL/UK(IE)

• 1 vCPU
• 1GB RAM
• 20GB NVMe (System) + 1TB SSD Storage
• Unmetered @ 100Mbps
• 1 IPv4 + /48 IPv6
• Location: Albania
• 25€/yr

• 1 vCPU
• 1GB RAM
• 1TB NVMe Storage
• Unmetered @ 1Gbps
• 1 IPv4 + /48 IPv6
• Location: UK with IPs Ireland Geo (IE)
• 25€/yr

---

Notes:

• PayPal Only (All BF deals must be paid via PayPal)
• Manual Setup: Setup is performed manually, usually within 1 hour (varies by time of purchase)
• No Reservations: Cancelling at checkout does not reserve your slot. Your spot is ecured only after PayPal payment completion
• Batch Processing: VPS servers are setup in batches. Account and VPS details will be emailed after setup is complete
• Final Sale: Stock is extremely limited. Once sold out, these deals will NOT return. Payments are final. No refunds on promotions.

Paid but it did not ask for account registration. What next?

We work on Albanian Time, we have just woken up for the day here.

We are checking the orders now and having some coffee - then we will process them.

There may have been a glitch - I'm seeing multiple orders for the same product here. Some may be refunded. Only the first one will be accepted. (multiple people had the payment page already up when the first paid and locked it, so all of them that were on PayPal already paid. Which isn't an issue - it just means we will have to refund some, we obviously can't honor 16 storage deals that large due to a glitch).

The first ones of each will receive an email from support {at} avsisp.com asking for which OS and the email address on your account (if different than paypal). The others will receive a prompt refund.

Apologies for any delays. Posts here on LET may not align with our operating hours, of course - which may lead to slight delays between post / order and us processing them.

Thank you for understanding.

So that means only two orders will actually go through? I really thought this was going to be the best deal I snagged for BF2025. Thanks for the generosity anyway, and huge congrats to the two lucky winners !

Yes, of course - they were intended to be limit 1 of each deal. But what happened was LET people have those fast fingers and multiple of you opened the page at the exact same time, proceeded to PayPal at the exact same time, and paid at the exact same time before one paid and locked the page. Down to the ms, they were within 2ms of eachother which is insanely fast on you guy's part (I love the enthusiasm! Thanks for the support!).

Refunds have already been issued. I think it's better we don't post publicly the emails of the 2 that were actually first, so I'll just say to check if you were refunded. If you got a refund, you weren't the first. If you didn't see a refund, you were first and you'll get a support email shortly with questions on OS and account email.

Apologies again for this glitch.

Too bad for them, need to wait for more than month to get their money back, because of faulty system to not recheck things

It isn't a faulty system. It's PayPal themselves. We relied on their system to handle that. So now PayPal is a faulty system? Makes sense.... For sure..

As for a month, that's entirely incorrect.
1) if you paid with PayPal balance, it's instantly back
2) if you paid with linked bank, it's just cancelled and never gets pulled - no money ever moves
3) if you paid with card, it's instant for USA Visa/MC usually and for other countries or card types it's 3 days max, usually in 24 hours or less.

Again, apologies, but we had no way to control this glitch. You guys are just too fast - this isn't the first time this has happened in LET history. It's happened with WHMCS using hosts, hostbill hosts, etc. payments make it through but product OOS and then payment cancelled or refunded. It's quiet a normal glitch and isn't one that can be solved unless you're a bank with the computer processing payments directly connected to your website which would be illegal but yeah - 2ms isn't enough time for notifications to cut transactions to come. And if you're already on the payment page, PayPal is going to accept that payment, even if the order page is already disabled. That's a PayPal issue - not one we can control. And again, with 2ms differences in payment times, I'm not sure any system in the world could have stopped that glitch regardless. Try to ping your own phone from your laptop in the same house or something some time. That's 2ms or more...

You shouldn't be relying on the payment provider to marshall who got the deal first. If someone has got to the stage where they've already been offered a deal and paid the advertised price, you should honour it.

If you only have one deal to sell, you should raise the invoice to whoever gets there first, and you can do that locally and ensure there is only one. If they don't pay the invoice in a reasonable timeframe, then cancel the order and restart the offer.

Again, that wouldn't have worked in this case. They were 2ms apart. They were at the page at the same time. There's no way it could have been prevented. PayPal themselves didn't stop it - on WHMCS with a limit 1 product even we've had this happen before. So what you're saying is incorrect and isn't compatible with how programming, APIs, internet latency, etc work.

We did the responsible thing and refunded them because we don't oversell our servers. We can't very-well sell 16TB of space when we can't guarantee that much space on the servers.

Apologies again to anyone refunded. But in the end, there was not other options for us but to handle it responsibly and give people their money back. We aren't some shady host that will oversell it rediculously to make a quick buck. We try to be responsible and not to oversell what we have available. If these had all been on Albania, it's possible we could have just added drives. But they were mostly for London - where we have less control to upgrade servers, especially without massive downtime.

Incorrect. They were on payment page at same time. Race condition wasn't possible to correct with 2ms differences.

You are naive, paypal job is to handle payment, not checking your stock

As "no way it could have been prevented", then you have problem with your stack, you didnt check if someone already click pay, you didnt check if someone already at paypal page, you didnt check if someone already have invoice in that product

So "Race condition wasn't possible to correct with 2ms differences." is also incorrect, you assume that the problem is the computational, or are you use old CPU for your server?

2ms, you say 2ms is impossible to correct, thats must be a joke, even in finance, such error is enormous

Also "They were on payment page at same time" this is your problem to let this happen, clearly not preparing the sudden visit.

You should read how to use single thread database, especially sqlite, it lock away shit when its updating, obviously will fix your "Race condition wasn't possible to correct with 2ms differences."

Read my last reply. We did indeed lockfile it. But everyone was on PayPal, not on our website. Our website page was locked. Anyone new coming to it got an out of stock. Those already at PayPal our system can't stop. PayPal link had a stock limit 1. I've already submitted a PayPal ticket to tell them what happened and ask them why their stock control on managed button links didn't work.

I have read, you are playing with yourself, lockfile in multithread, obviously will error

You take the shortcut and playing with people money instead

Here simple explanation on your "solution"

We have 3 teller, each will check the vault to tell customer its has gold in it before taking order, but to get to vault it need 1 minutes go and 1 minute back to check the gold

teller 1, on 01:00 check there is gold!
teller 2, on 01:01 take the gold!
teller 1, on 02:00 tell the customer there is a gold!

THATS THE PROBLEM

Instead of delegating the checking mechanism to 1 guy (single thread - 1 concurency table) to check the gold, you gamble that that time frame is enough to check the gold

Again, and this will be my last reply to this - we have a lot of work to tackle today....

There was multi-step limits and checks. The final one to fail was on PayPal, not at us. PayPal link had a strict stock limit of 1. PayPal still allowed 16 to go through. So yeah, sure, we could have paid 10k to a programmer to rewrite our entire stack to end up at the exact same situation regardless.

We did what we could. We refunded the ones that were oversold and that's all we could do. We've submitted a ticket to PayPal. There is nothing further we could or can do. So if all of your suggested ideas of how transactions within ms of each-other work - a multi-billion dollar company like PayPal you would think would have implemented them - but obviously didn't.

Apologies for the final time to anyone that was effected and got a refund.

It's fine if you don't want to reply again, but seriously actually read what we are saying.

Concurrency is a solved problem. It was a solved problem years ago. People were worrying about how to create reliable locking on filesystems 30+ years ago. This is exactly why the semantics of creating a symlink are like they are now. None of this is new or rocket science.

If you continue to believe that you did everything right, then you will have exactly the same problem in the future. And you will continue to incorrectly argue with everyone that you did everything you could.

But if you take the time to read what we are saying, and try to understand how the multiple suggestions given to you would actually solve the problem, then you could easily stop this problem from happening again. It just requires you to open your mind to the possibility that there are solutions to this problem that work.

For the final time - on our side it worked correctly. It was locked. Nobody new could order or get to the PayPal. They were ALREADY AT PAYPAL. PayPal link had a LIMIT OF 1 STOCK. PayPal allowed 16 to order what was limited to 1.

Do you see where this is going?

Concurrency isn't the issue. It's Apache with PHP. It's obviously concurrent regardless. You can't very-well limit a website to 1 visitor at a time - that's just insanity.

How this can be solved and will be in the future to avoid these issues - everyone must have an account to make an order, there'll be a delay added to when the PayPal forward happens with 3 checks first, and it'll be slow to get to PayPal to pay but won't happen again oversell like that.

So in the future, nobody will be able to order without an account. We tried it for these specials only to avoid people having to create accounts before they order, to streamline it. And this happened - so from now on, everything is locked inside our panel and nobody can order without an existing account. Problem solved.

you’re right — inventory can’t be managed through PayPal. It has to be done through your account’s billing system.

ralf

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@Maki said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@senos said:

@avsisp said:

@FAT32 said:

01/12 00:00

AVS ISP: 25€/yr 1TB SSD/NVME Unmetered Storage VPS in AL/UK(IE)

• 1 vCPU
• 1GB RAM
• 20GB NVMe (System) + 1TB SSD Storage
• Unmetered @ 100Mbps
• 1 IPv4 + /48 IPv6
• Location: Albania
• 25€/yr

• 1 vCPU
• 1GB RAM
• 1TB NVMe Storage
• Unmetered @ 1Gbps
• 1 IPv4 + /48 IPv6
• Location: UK with IPs Ireland Geo (IE)
• 25€/yr

---

Notes:

• PayPal Only (All BF deals must be paid via PayPal)
• Manual Setup: Setup is performed manually, usually within 1 hour (varies by time of purchase)
• No Reservations: Cancelling at checkout does not reserve your slot. Your spot is ecured only after PayPal payment completion
• Batch Processing: VPS servers are setup in batches. Account and VPS details will be emailed after setup is complete
• Final Sale: Stock is extremely limited. Once sold out, these deals will NOT return. Payments are final. No refunds on promotions.

Paid but it did not ask for account registration. What next?

We work on Albanian Time, we have just woken up for the day here.

We are checking the orders now and having some coffee - then we will process them.

There may have been a glitch - I'm seeing multiple orders for the same product here. Some may be refunded. Only the first one will be accepted. (multiple people had the payment page already up when the first paid and locked it, so all of them that were on PayPal already paid. Which isn't an issue - it just means we will have to refund some, we obviously can't honor 16 storage deals that large due to a glitch).

The first ones of each will receive an email from support {at} avsisp.com asking for which OS and the email address on your account (if different than paypal). The others will receive a prompt refund.

Apologies for any delays. Posts here on LET may not align with our operating hours, of course - which may lead to slight delays between post / order and us processing them.

Thank you for understanding.

So that means only two orders will actually go through? I really thought this was going to be the best deal I snagged for BF2025. Thanks for the generosity anyway, and huge congrats to the two lucky winners !

Yes, of course - they were intended to be limit 1 of each deal. But what happened was LET people have those fast fingers and multiple of you opened the page at the exact same time, proceeded to PayPal at the exact same time, and paid at the exact same time before one paid and locked the page. Down to the ms, they were within 2ms of eachother which is insanely fast on you guy's part (I love the enthusiasm! Thanks for the support!).

Refunds have already been issued. I think it's better we don't post publicly the emails of the 2 that were actually first, so I'll just say to check if you were refunded. If you got a refund, you weren't the first. If you didn't see a refund, you were first and you'll get a support email shortly with questions on OS and account email.

Apologies again for this glitch.

Too bad for them, need to wait for more than month to get their money back, because of faulty system to not recheck things

It isn't a faulty system. It's PayPal themselves. We relied on their system to handle that. So now PayPal is a faulty system? Makes sense.... For sure..

As for a month, that's entirely incorrect.
1) if you paid with PayPal balance, it's instantly back
2) if you paid with linked bank, it's just cancelled and never gets pulled - no money ever moves
3) if you paid with card, it's instant for USA Visa/MC usually and for other countries or card types it's 3 days max, usually in 24 hours or less.

Again, apologies, but we had no way to control this glitch. You guys are just too fast - this isn't the first time this has happened in LET history. It's happened with WHMCS using hosts, hostbill hosts, etc. payments make it through but product OOS and then payment cancelled or refunded. It's quiet a normal glitch and isn't one that can be solved unless you're a bank with the computer processing payments directly connected to your website which would be illegal but yeah - 2ms isn't enough time for notifications to cut transactions to come. And if you're already on the payment page, PayPal is going to accept that payment, even if the order page is already disabled. That's a PayPal issue - not one we can control. And again, with 2ms differences in payment times, I'm not sure any system in the world could have stopped that glitch regardless. Try to ping your own phone from your laptop in the same house or something some time. That's 2ms or more...

You shouldn't be relying on the payment provider to marshall who got the deal first. If someone has got to the stage where they've already been offered a deal and paid the advertised price, you should honour it.

If you only have one deal to sell, you should raise the invoice to whoever gets there first, and you can do that locally and ensure there is only one. If they don't pay the invoice in a reasonable timeframe, then cancel the order and restart the offer.

Again, that wouldn't have worked in this case. They were 2ms apart. They were at the page at the same time. There's no way it could have been prevented. PayPal themselves didn't stop it - on WHMCS with a limit 1 product even we've had this happen before. So what you're saying is incorrect and isn't compatible with how programming, APIs, internet latency, etc work.

We did the responsible thing and refunded them because we don't oversell our servers. We can't very-well sell 16TB of space when we can't guarantee that much space on the servers.

Apologies again to anyone refunded. But in the end, there was not other options for us but to handle it responsibly and give people their money back. We aren't some shady host that will oversell it rediculously to make a quick buck. We try to be responsible and not to oversell what we have available. If these had all been on Albania, it's possible we could have just added drives. But they were mostly for London - where we have less control to upgrade servers, especially without massive downtime.

Incorrect. They were on payment page at same time. Race condition wasn't possible to correct with 2ms differences.

You are naive, paypal job is to handle payment, not checking your stock

As "no way it could have been prevented", then you have problem with your stack, you didnt check if someone already click pay, you didnt check if someone already at paypal page, you didnt check if someone already have invoice in that product

So "Race condition wasn't possible to correct with 2ms differences." is also incorrect, you assume that the problem is the computational, or are you use old CPU for your server?

2ms, you say 2ms is impossible to correct, thats must be a joke, even in finance, such error is enormous

Also "They were on payment page at same time" this is your problem to let this happen, clearly not preparing the sudden visit.

You should read how to use single thread database, especially sqlite, it lock away shit when its updating, obviously will fix your "Race condition wasn't possible to correct with 2ms differences."

Read my last reply. We did indeed lockfile it. But everyone was on PayPal, not on our website. Our website page was locked. Anyone new coming to it got an out of stock. Those already at PayPal our system can't stop. PayPal link had a stock limit 1. I've already submitted a PayPal ticket to tell them what happened and ask them why their stock control on managed button links didn't work.

I have read, you are playing with yourself, lockfile in multithread, obviously will error

You take the shortcut and playing with people money instead

Here simple explanation on your "solution"

We have 3 teller, each will check the vault to tell customer its has gold in it before taking order, but to get to vault it need 1 minutes go and 1 minute back to check the gold

teller 1, on 01:00 check there is gold!
teller 2, on 01:01 take the gold!
teller 1, on 02:00 tell the customer there is a gold!

THATS THE PROBLEM

Instead of delegating the checking mechanism to 1 guy (single thread - 1 concurency table) to check the gold, you gamble that that time frame is enough to check the gold

Again, and this will be my last reply to this - we have a lot of work to tackle today....

There was multi-step limits and checks. The final one to fail was on PayPal, not at us. PayPal link had a strict stock limit of 1. PayPal still allowed 16 to go through. So yeah, sure, we could have paid 10k to a programmer to rewrite our entire stack to end up at the exact same situation regardless.

We did what we could. We refunded the ones that were oversold and that's all we could do. We've submitted a ticket to PayPal. There is nothing further we could or can do. So if all of your suggested ideas of how transactions within ms of each-other work - a multi-billion dollar company like PayPal you would think would have implemented them - but obviously didn't.

Apologies for the final time to anyone that was effected and got a refund.

It's fine if you don't want to reply again, but seriously actually read what we are saying.

Concurrency is a solved problem. It was a solved problem years ago. People were worrying about how to create reliable locking on filesystems 30+ years ago. This is exactly why the semantics of creating a symlink are like they are now. None of this is new or rocket science.

If you continue to believe that you did everything right, then you will have exactly the same problem in the future. And you will continue to incorrectly argue with everyone that you did everything you could.

But if you take the time to read what we are saying, and try to understand how the multiple suggestions given to you would actually solve the problem, then you could easily stop this problem from happening again. It just requires you to open your mind to the possibility that there are solutions to this problem that work.

For the final time - on our side it worked correctly. It was locked. Nobody new could order or get to the PayPal. They were ALREADY AT PAYPAL. PayPal link had a LIMIT OF 1 STOCK. PayPal allowed 16 to order what was limited to 1.

AND THAT IS EXACTLY THE PROBLEM. YOU SHOULDN'T HAVE LET TWO PEOPLE GET TO PAYPAL IN THE FIRST PLACE.

Do you see where this is going?

Yes, you still refuse to accept that there's any other possible solution to the problem than the one that you tried that (very clearly) doesn't work.

Concurrency isn't the issue. It's Apache with PHP. It's obviously concurrent regardless. You can't very-well limit a website to 1 visitor at a time - that's just insanity.

You don't need to limit the web site to 1 visitor at a time. As you say, that would be insanity.

However, if you only have a single product to sell, you can very easily limit that single product to only one person. That is entirely within your control. You can decide who was first well before passing them on to paypal.

How this can be solved and will be in the future to avoid these issues - everyone must have an account to make an order, there'll be a delay added to when the PayPal forward happens with 3 checks first, and it'll be slow to get to PayPal to pay but won't happen again oversell like that.

No. There's no need for people to have an account to make an order to ensure that only one person gets from your site to paypal.

So in the future, nobody will be able to order without an account. We tried it for these specials only to avoid people having to create accounts before they order, to streamline it. And this happened - so from now on, everything is locked inside our panel and nobody can order without an existing account. Problem solved.

I mean, you do whatever suits you. But you know that the solution you currently have doesn't work. I'm just suggesting how you might improve the process for the future. But as the saying goes, you can lead a horse to water, but you can't make them drink.

doobydoe

spaceowl

I don't think atheists worship Darwin

Murv

@Hitori0221 said:
who can sponsor this poor college student to pay for their gigahost bill?

https://www.nodeseek.com/post-527153-1

So that's what MJJ shitpost looks like

avsisp

@tansel said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@Maki said:

@avsisp said:

@ralf said:

@avsisp said:

@Maki said:

@avsisp said:

@senos said:

@avsisp said:

@FAT32 said:

01/12 00:00

AVS ISP: 25€/yr 1TB SSD/NVME Unmetered Storage VPS in AL/UK(IE)

• 1 vCPU
• 1GB RAM
• 20GB NVMe (System) + 1TB SSD Storage
• Unmetered @ 100Mbps
• 1 IPv4 + /48 IPv6
• Location: Albania
• 25€/yr

• 1 vCPU
• 1GB RAM
• 1TB NVMe Storage
• Unmetered @ 1Gbps
• 1 IPv4 + /48 IPv6
• Location: UK with IPs Ireland Geo (IE)
• 25€/yr

---

Notes:

• PayPal Only (All BF deals must be paid via PayPal)
• Manual Setup: Setup is performed manually, usually within 1 hour (varies by time of purchase)
• No Reservations: Cancelling at checkout does not reserve your slot. Your spot is ecured only after PayPal payment completion
• Batch Processing: VPS servers are setup in batches. Account and VPS details will be emailed after setup is complete
• Final Sale: Stock is extremely limited. Once sold out, these deals will NOT return. Payments are final. No refunds on promotions.

Paid but it did not ask for account registration. What next?

We work on Albanian Time, we have just woken up for the day here.

We are checking the orders now and having some coffee - then we will process them.

There may have been a glitch - I'm seeing multiple orders for the same product here. Some may be refunded. Only the first one will be accepted. (multiple people had the payment page already up when the first paid and locked it, so all of them that were on PayPal already paid. Which isn't an issue - it just means we will have to refund some, we obviously can't honor 16 storage deals that large due to a glitch).

The first ones of each will receive an email from support {at} avsisp.com asking for which OS and the email address on your account (if different than paypal). The others will receive a prompt refund.

Apologies for any delays. Posts here on LET may not align with our operating hours, of course - which may lead to slight delays between post / order and us processing them.

Thank you for understanding.

So that means only two orders will actually go through? I really thought this was going to be the best deal I snagged for BF2025. Thanks for the generosity anyway, and huge congrats to the two lucky winners !

Yes, of course - they were intended to be limit 1 of each deal. But what happened was LET people have those fast fingers and multiple of you opened the page at the exact same time, proceeded to PayPal at the exact same time, and paid at the exact same time before one paid and locked the page. Down to the ms, they were within 2ms of eachother which is insanely fast on you guy's part (I love the enthusiasm! Thanks for the support!).

Refunds have already been issued. I think it's better we don't post publicly the emails of the 2 that were actually first, so I'll just say to check if you were refunded. If you got a refund, you weren't the first. If you didn't see a refund, you were first and you'll get a support email shortly with questions on OS and account email.

Apologies again for this glitch.

Too bad for them, need to wait for more than month to get their money back, because of faulty system to not recheck things

It isn't a faulty system. It's PayPal themselves. We relied on their system to handle that. So now PayPal is a faulty system? Makes sense.... For sure..

As for a month, that's entirely incorrect.
1) if you paid with PayPal balance, it's instantly back
2) if you paid with linked bank, it's just cancelled and never gets pulled - no money ever moves
3) if you paid with card, it's instant for USA Visa/MC usually and for other countries or card types it's 3 days max, usually in 24 hours or less.

Again, apologies, but we had no way to control this glitch. You guys are just too fast - this isn't the first time this has happened in LET history. It's happened with WHMCS using hosts, hostbill hosts, etc. payments make it through but product OOS and then payment cancelled or refunded. It's quiet a normal glitch and isn't one that can be solved unless you're a bank with the computer processing payments directly connected to your website which would be illegal but yeah - 2ms isn't enough time for notifications to cut transactions to come. And if you're already on the payment page, PayPal is going to accept that payment, even if the order page is already disabled. That's a PayPal issue - not one we can control. And again, with 2ms differences in payment times, I'm not sure any system in the world could have stopped that glitch regardless. Try to ping your own phone from your laptop in the same house or something some time. That's 2ms or more...

You shouldn't be relying on the payment provider to marshall who got the deal first. If someone has got to the stage where they've already been offered a deal and paid the advertised price, you should honour it.

If you only have one deal to sell, you should raise the invoice to whoever gets there first, and you can do that locally and ensure there is only one. If they don't pay the invoice in a reasonable timeframe, then cancel the order and restart the offer.

Again, that wouldn't have worked in this case. They were 2ms apart. They were at the page at the same time. There's no way it could have been prevented. PayPal themselves didn't stop it - on WHMCS with a limit 1 product even we've had this happen before. So what you're saying is incorrect and isn't compatible with how programming, APIs, internet latency, etc work.

We did the responsible thing and refunded them because we don't oversell our servers. We can't very-well sell 16TB of space when we can't guarantee that much space on the servers.

Apologies again to anyone refunded. But in the end, there was not other options for us but to handle it responsibly and give people their money back. We aren't some shady host that will oversell it rediculously to make a quick buck. We try to be responsible and not to oversell what we have available. If these had all been on Albania, it's possible we could have just added drives. But they were mostly for London - where we have less control to upgrade servers, especially without massive downtime.

Incorrect. They were on payment page at same time. Race condition wasn't possible to correct with 2ms differences.

You are naive, paypal job is to handle payment, not checking your stock

As "no way it could have been prevented", then you have problem with your stack, you didnt check if someone already click pay, you didnt check if someone already at paypal page, you didnt check if someone already have invoice in that product

So "Race condition wasn't possible to correct with 2ms differences." is also incorrect, you assume that the problem is the computational, or are you use old CPU for your server?

2ms, you say 2ms is impossible to correct, thats must be a joke, even in finance, such error is enormous

Also "They were on payment page at same time" this is your problem to let this happen, clearly not preparing the sudden visit.

You should read how to use single thread database, especially sqlite, it lock away shit when its updating, obviously will fix your "Race condition wasn't possible to correct with 2ms differences."

Read my last reply. We did indeed lockfile it. But everyone was on PayPal, not on our website. Our website page was locked. Anyone new coming to it got an out of stock. Those already at PayPal our system can't stop. PayPal link had a stock limit 1. I've already submitted a PayPal ticket to tell them what happened and ask them why their stock control on managed button links didn't work.

I have read, you are playing with yourself, lockfile in multithread, obviously will error

You take the shortcut and playing with people money instead

Here simple explanation on your "solution"

We have 3 teller, each will check the vault to tell customer its has gold in it before taking order, but to get to vault it need 1 minutes go and 1 minute back to check the gold

teller 1, on 01:00 check there is gold!
teller 2, on 01:01 take the gold!
teller 1, on 02:00 tell the customer there is a gold!

THATS THE PROBLEM

Instead of delegating the checking mechanism to 1 guy (single thread - 1 concurency table) to check the gold, you gamble that that time frame is enough to check the gold

Again, and this will be my last reply to this - we have a lot of work to tackle today....

There was multi-step limits and checks. The final one to fail was on PayPal, not at us. PayPal link had a strict stock limit of 1. PayPal still allowed 16 to go through. So yeah, sure, we could have paid 10k to a programmer to rewrite our entire stack to end up at the exact same situation regardless.

We did what we could. We refunded the ones that were oversold and that's all we could do. We've submitted a ticket to PayPal. There is nothing further we could or can do. So if all of your suggested ideas of how transactions within ms of each-other work - a multi-billion dollar company like PayPal you would think would have implemented them - but obviously didn't.

Apologies for the final time to anyone that was effected and got a refund.

It's fine if you don't want to reply again, but seriously actually read what we are saying.

Concurrency is a solved problem. It was a solved problem years ago. People were worrying about how to create reliable locking on filesystems 30+ years ago. This is exactly why the semantics of creating a symlink are like they are now. None of this is new or rocket science.

If you continue to believe that you did everything right, then you will have exactly the same problem in the future. And you will continue to incorrectly argue with everyone that you did everything you could.

But if you take the time to read what we are saying, and try to understand how the multiple suggestions given to you would actually solve the problem, then you could easily stop this problem from happening again. It just requires you to open your mind to the possibility that there are solutions to this problem that work.

For the final time - on our side it worked correctly. It was locked. Nobody new could order or get to the PayPal. They were ALREADY AT PAYPAL. PayPal link had a LIMIT OF 1 STOCK. PayPal allowed 16 to order what was limited to 1.

Do you see where this is going?

Concurrency isn't the issue. It's Apache with PHP. It's obviously concurrent regardless. You can't very-well limit a website to 1 visitor at a time - that's just insanity.

How this can be solved and will be in the future to avoid these issues - everyone must have an account to make an order, there'll be a delay added to when the PayPal forward happens with 3 checks first, and it'll be slow to get to PayPal to pay but won't happen again oversell like that.

So in the future, nobody will be able to order without an account. We tried it for these specials only to avoid people having to create accounts before they order, to streamline it. And this happened - so from now on, everything is locked inside our panel and nobody can order without an existing account. Problem solved.

you’re right — inventory can’t be managed through PayPal. It has to be done through your account’s billing system.

Incorrect. PayPal hosted links allow for a stock limit. However, it obviously failed in this case. Anyways - we live and we learn. In the future, we will do it differently, introducing intentional delays, making users login or register first, etc.

ralf

@avsisp said:
Anyways - we live and we learn. In the future, we will do it differently,

Great!

introducing intentional delays, making users login or register first, etc.

Oh.

beanman109

@Hitori0221 said:
who can sponsor this poor college student to pay for their gigahost bill?

https://www.nodeseek.com/post-527153-1

this makes me sad how do i get the mjj to give to me instead