What stack are you running? How do you guarantee sequential consistency of order numbers across your app server regions, cache layers and data lakehouse?
Removing choice is fine, but people will want to know what number they'll get if they order right now. Even if you can't or won't show the next rock, show the next number.
Say the server has a counter. When you load the page, it's at 57, so it displays that you would be ordering #57. While you're looking at this, someone else loads the page - what number do you show them? If you show 57, then whoever orders first gets it and the other person gets a message "Sorry, not available. Want 58 instead?" but the same thing could then happen to them with #58, too – "Sorry, not available. Want 59 instead?"
So maybe instead you show the 2nd person counter+1, i.e. 58. And you show the 3rd person counter+2, i.e. 59. But what if #59 purchases but 57 and 58 don't? What do you show the NEXT person, 57 or 60?
I'm not saying it's intractable but it merits thought.
IIRC many websites (e.g. for buying concert tickets) have a lock mechanism where you have X amount of time to make your purchase during which time only a limited number of people can be in the checkout process.
We're avoiding any reservation or lock mechanisms entirely. Starting November 1, the site will display 'Most recent fulfillment: Rock #000047' to show systematic progress, but this creates no guarantee for future purchases.
Sequential assignment follows strict order of payment completion only. No race conditions, no held inventory, no time windows. You either complete the transaction and receive the next sequential number, or you don't.
The constraint is designed to eliminate the entire apparatus of purchase optimization, including queue management systems.
Rocks are not physically modified. Sequential numbering exists in our documentation system only - reflected on the Certificate of Authenticity and archive database. The rocks themselves remain in their natural state.
Correct - the rocks are numbered but the number is not physically on the surface of the rock. Sequential assignment exists in our documentation system only - reflected on the Certificate of Authenticity and archive database. The rocks remain in their natural state. We have no plans to launch an un-numbered version of weight.rocks
“All park resources are protected so that all visitors may enjoy them. It is against the law to remove any of the natural (petrified wood, other rocks, plants, animals) or cultural resources (pottery pieces, arrowheads, Route 66 debris), including picking flowers.”
It's funny you ask, I had this exact idea back during the NFT craze. I have an unlimited supply of rocks thanks to the creek in my back yard. Well not unlimited, but there are more rocks back there than people willing to buy them as a joke.
Yeah but where is the blog post about bootstrapping webscale rocks from the ground up? Where are the growth hacks? This could be a tectonic shift in the startup ecosystem. Watching this thread you guys rock!
Quick question... Have you considered letting customers come mine their own rocks?
I’ve bought a lot from eBay (since 1998) and the joy of buying unique items is knowing the photo is of the exact object I’m receiving. Further from this experience, I understand the appeal less and less.
Rock assignment follows purchase order - no reservations possible. Each order is limited to one rock. If you want multiple rocks, place separate orders, but other customers may complete purchases between yours, interrupting sequential numbering. Assignment remains systematic and cannot be influenced by preference.
