Delivery You Can Trust
Fasty has one golden rule: the customer always gets the product. The server organizes things, but if it goes down, your store keeps selling. This page explains how.
The sale is safe from the first second
The moment a customer pays, the vendor gives the sale a unique ID and saves it in its own memory before talking to anyone. From then on, that sale exists even if every server in the world disappears. It only leaves the vendor's memory once someone confirms it is safe.
That ID also prevents duplicates: the same sale arriving twice (from the vendor and from the hub, for example) is recognised and counted once.
The backup paths
The vendor tries each path in order, with short waits:
The Fasty server. The normal path. The server registers the sale and orders a hub to deliver.
Straight to the hub. If the server doesn't answer in about 8 seconds, the vendor sends the sale directly to a hub it knows. The hub delivers and keeps a note of it.
Ask the backup registry. If the hub moved (a region restart gives it a new address), the vendor asks a small backup service where your hubs are now, then tries again.
The next hub. Still nothing? It tries your backup hubs.
Keep it and keep trying. If nothing answers, the vendor tells the customer by IM that the purchase is guaranteed and will arrive soon. It tries again on its own, waiting a little longer each time (seconds, then minutes).
When the server comes back, it collects everything that happened while it was away (from the hubs and from the backup registry's notes) and your panel catches up. Points, profit shares and stats included. The only thing you miss is the purchase IM for sales that went straight to the hub.
On the server side
When the server is up and a hub doesn't confirm a delivery:
- No answer in 10 seconds → it sends the order to the next hub.
- The hub took the order but didn't confirm in 2 minutes → it asks the hub; if the hub is silent, another hub delivers.
- Following "when in doubt, deliver again": a duplicate copy is harmless, a missing one is not.
Fasty never gives up on a delivery. A hub that is down for hours, an item that left every hub for a while: Fasty keeps trying every few minutes, and the item goes out as soon as a hub can deliver it. You never have to redeliver a sale by hand because Fasty stopped trying.
Gifts to offline avatars
Second Life can lose items given to offline avatars. So the hub checks first and delivers gifts while the recipient is online, retrying every 5 minutes. After 24 hours, it sends anyway and Second Life keeps the offer for them. The same goes for products sent from the panel, giveaway prizes and points trades. See Gifts.
Price changes reach every vendor
When you change a price, a sale starts or ends, or a vendor gets a new product, Fasty nudges the vendors involved and they fetch the change in about a second. A vendor that doesn't answer (a busy region) is nudged again for a few minutes until it does. A vendor on land without free script URLs catches up on its next check-in (up to 15 minutes). Touch it → Refresh to fetch right now.
What you see in the panel
| Situation | Where you see it |
|---|---|
| A hub went offline | Home: "Main Store Hub is offline. Sales are going to Backup Hub; no customer was left without their item." |
| Sales waiting | Home: "2 sales waiting for delivery. They are guaranteed." · Sales: status Waiting |
| A vendor still holding sales | Its owner menu in Second Life: "2 sale(s) being delivered automatically." |
| How a sale got delivered | The sale's delivery path: Delivered straight by the hub (server down), Backup registry found the hub, Backup hub… |
Tested the hard way
Before release, Fasty was put through a chaos test: 200 vendors selling 40 sales per second while the server was killed twice on purpose, hubs went offline (alone and together with the server) and database connections were cut. Result: 4,520 sales, none lost, none duplicated, all delivered.
What you can do
Keep a backup hub in another region with the same items. It is the single best thing you can do for your store's reliability. See Hubs.