I am looking to help solve a client’s problem related to their shopping cart system. They have a home grown e-commerce wholesale purchasing site. They have independent reps that come in and purchase clothing to resale at parties or events. This wouldn’t be a problem but they run their sales based on flash sales.
The company makes an announcement of new products going on sale Monday, but doesn’t announce what the products are. The products launch at 11:00am but a preview is opened at 9:00am. When 11:00am hits the site usage completely spikes getting somewhere around 60K requests per second.
Can aerospike quickly handle a large amount of reads and writes to the same object? Namely, checking inventory stock level and decrementing the stock level when an item is placed in cart? We cannot allow a Rep to think they have an item in their cart and then find out it is out of stock when they checkout.
Any insight to this use case for Aerospike would be great.
I don’t think that would be a problem, especially if it was an in-memory configuration, but I’ll defer to the other folks that have more experience giving that advice here. @kporter@rbotzer also you mentioned 60k per second but 200*20=4000?
Sorry, the 60K per second is total requests into the system.
Our biggest problem is managing a giant spike in usage for these sales times. They are scheduled in advance so we know when they are going to happen, but the current aurora system we have doesn’t scale up well (We have to take the site down just to increase the DBs).
What is the distribution of read/write on the object? 200 hits per second is the write volume? I think it will work, but you should probably test it out (in-memory config if you can) and maybe reach out to the support/sales team direct. Contact Us | Aerospike
200 operations per-second on a record should not be a problem.
When modeling for Aerospike you should be thinking about the access patterns, rather than come with a document store approach of everything being a single huge object.
Your product object can and should live in a namespace that stores its data on SSD. This object’s attributes will not change all that often, and it’s relatively large.
The inventory counter for this object, which is an integer value that changes rapidly (relative to how often any other attribute changes), should likely live in a namespace that stores its data in memory, with persistence to disk. Try to take advantage of data-in-index, a special case of in-memory storage for counters. Take a look Storage Engine Configuration Recipes.
This way you can efficiently handle a large number of atomic decrement operations to the counter, while still providing great read latency for both the product object on SSD and the counter. Your application will use the client to read both, and update the in-memory counter.
By the way, if the inventory has to be absolutely precise you should consider Aerospike EE 4.0 when it comes out, for strong consistency.
See Srini’s The 7 Year Itch engineering blog post (parts 1 & 2) which explains the upcoming strong consistency with high performance, versus the current high availability mode of Aerospike EE 3.x.
Thanks for your responses @rbotzer and @Albot these details are great! If I’m able to put a solid POC together we will definitely look into EE. This seems like a system that will totally work for our needs.