Aerospike (the fastest read/write database that operates in-memory, on flash, as a hybrid and on disk as well) is now open source under the Free Software Foundation’s AGPL License, while its client software SDK became available under the Apache license.

Especially for Internet-scale applications in travel, this is a huge deal because it presents a modern open source alternative to ancient and fairly expensive tech that has powered a number of caches in legacy travel infrastructure… but also sucked the lifeblood out of many a company. At the same time, it provides hot read/write performance far exceeding open projects in common usage such as Mongo and Cassandra, often by a factor of 10 or more.

The good, the bad and the ugly… and not necessarily in that order

As part of our advisory work at Hudson Crossing, we routinely suggest to clients that the increasing demands for dynamic rate marketing, continuous rate management optimizations, cross-sell, and personalization create a problem space that is best addressed with modern Internet-scale tools.

Tools that disappoint in this new world (either in technical performance, development efficiency or cost-effectiveness terms) break down between legacy big-software stacks and various open source components.

Among the big-software stacks: Oracle’s ATG + Endeca + Coherence and SAP’s Hybris + Solr + HANA

• These Product Information Management (PIM) + indexing + in-memory tier options are nice for static e-commerce inventory where prices change fairly slowly… like grocery stores and physical goods e-commerce sites, but otherwise expensive and clunky to tune, even when the PIM is not included).
• While it is possible, and some would argue “safe”, to build a large-scale solution with them, we’ve never seen true dynamic read/write travel projects use one of these and fail to disappoint, be late, or escalate the bill into the several million dollars in licenses alone, before customization piles on about double the cost.

Among the open source components: Cassandra, Mongo, Couchbase, Redis

• These are a bit like a complex Swiss knife. If you know what you’re doing they could do the job, but most people end up cutting their fingers instead. And those whose companies succeed and catch explosive growth find limits much sooner than they’d like.
• One of the aspects of using these that is often under-appreciated is the cost of hiring and keeping a high quality team that can take fairly raw ingredients and add the enterprise features needed for long term success. This is why we see examples of other companies such as MongoDB Inc. (formerly 10gen) and DataStax succeeding in the “commercial open source” model.

One alternative to both big-software legacy stuff and to other open source components that has proven itself under the most stringent circumstances is Aerospike, which has had great success among clients with truly challenging loads: Among its enthusiastic endorsers you’ll find some of the largest real-time ad bidding and e-commerce ecosystem platforms: AppNexus, BlueKai, SnapDeal, eBay, and many others.

Up to now, the main objection to Aerospike’s use had been its code not being open source. Now that’s dispensed with, and this opens the door for a lot of potential uses in travel.

So I thought I’d provide a few examples of why dynamic pricing & inventory in travel (coupled with lopsided look-to-book ratios) is an area calling for a core technology like Aerospike (both for the lightening speed it brings and for the great economic advantages of being able to deliver that speed from direct addressing of flash instead of more expensive DRAM.

It may be helpful to consider examples in travel (with names withheld to protect the guilty and with slightly obfuscated numbers to protect the innocent).

How does this affect a distributor of travel goods?

We've seen cases where companies were routinely victimized with over 150,000:1 search-to-book ratios. You might well say “Quoi, mais c’est pas possible!”

Why can such a thing happen? To paraphrase Maréchal Pierre Bosquet “ce n’est pas le commerce, c’est de la folie.” The complete exploration of the reasons why is a long story for a another day but here’s a short version:

• Whether it’s air, hotel, car rental or other services, end users don’t ask for price just once, but many times, in many Internet storefronts and from many devices.
• All those storefronts, desperate to get the sale, are in turn shopping one another to verify their price & availability position relative to competitive distributors and to the original travel brands themselves. In addition, analytics/BI companies are shopping everybody… you get the picture.
• Additionally, while 150,000:1 sounds ridiculous, look at it another way: suppose that on a per-destination basis you are at the receiving end of 7500:1 in broad based look-to-book requests for a destination. In a destination where at least 20 hotels out of 200 require individual pull searches then you would metastasize into (20 * 7500 + 1 bulk local search) or 150,001:1 searches-to-book.
• Clearly, a good case for heuristically optimized caching, but that also means the ability to be updating a very large cache with ongoing reads and writes.

At this point you might say, yes, but how is an airplane ticket or a hotel night different from buying a toy on Amazon or bananas from Walmart?

Part of the difference is this: PIM-driven e-commerce is relatively tame

• Amazon knows their stock position in most items, and also the related supply chain capabilities.
• The price is for all practical purposes fixed or changing rather slowly and therefore everything about a specific product can be cached: descriptives, prices, availability.
• Even better, as stocks deplete more copies can easily be made, just as more bananas can be ordered.

Hotel beds and airplane seats are a different matter

• For starters, having the bed or seat on the appointed time and day is crucial. So the commodity is as perishable as each ticking second and date-specific availability can change very fast.
• Additionally, hotel beds and airplane seats are revenue managed dynamically, and in fact increasingly so. From proven existing leaders like IDeaS to startups like Duetto everybody is taking revenue management from overnight batches to a real time dynamic world. To make the implications simple, let’s compare a couple of simplified and indeed simplistic uses cases in physical goods e-commerce vs. hospitality.
• Traditional e-commerce outfits, even gigantic ones like Amazon which might serve up prices and availability on something like 1 billion products worldwide, set a price and let it ride for a while. Even if the stock vanishes, Amazon can put up a note inviting users to per-order for a future date, and nobody thinks much of it.
• The net of it is that everything in this case is eminently cacheable. Pricing and availability can be cached, and when a purchase happens, decrementing availability is not rocket science.

Hospitality is dicey and full of under-appreciated complexities
For one thing a lot of distributors are not selling their own inventory, nor do they have fulfillment control over other people’s inventory. So distributors end up having to handle multiple properties either directly or indirectly through brand level systems.

• One single individual hotel may have 200 rooms broken among 5 room types (such as king, 2 queens, studio, jr. suite and suite). Additionally it may have defined 20 rate plans (such as AAA discount, corporate negotiated rates, weekend deals, advance purchase rates, rates with bundled amenities such as Wi-Fi or breakfast or both, etc). Then it may have stay pattern rules affecting prices and availability depending on the days or arrival and departure, and other rules around number of occupants, the applicable taxes depending on location and so on.
• Our friendly travel distributor is dealing not just with that hotel, but also with all the possible hotels in each particular destination. So every time a shopper asks about price and availability in NYC for 2 people from August 1st to 5th, 2014, you have 600 or more hotels involved with not only constantly changing availabilities but also constantly changing prices which have to be exploded into all the room type * rate plan * stay patterns permutations.

In air travel there are similar issues, compounded by a version of the “traveling salesman problem”

No, not an actual salesman…

• In air travel we’re talking about the classic computer science problem of having a graph (all the possible routes with connections between origin and destination).
• Where hotels have rate plans, airlines have a multiplicity of fare bases. The fare basis dictates conditions for cancelations and changes, upgradability, etc… and this means that what might like one plane with two cabins is really a complex web of multiple “products”.
• Explaining “legal” connections, interlining, and selfie-do connections without actual interlining is a whole other matter that may deserve its own write-up. But if you get the general idea, consider now the need to understand price and availability for every “legitimate” path in the graph even as airlines are changing availability and dynamically revenue managing costs on each segment, cabin, seat type and fare basis.
• Having a good (if expensive) answer to this problem is why ITA Software was worth $700 million dollars to Google, and why its leading challenger, Vayant Travel Technologies just received a significant strategic investment from Deutsche Lufthansa AG.
• It is also why major distributors of travel are hot with extraordinary computational challenges whether they’re facing the Internet as B2C players (leading Metas like Kayak, OTAs like Expedia), or B2B players (wholesalers like HotelBeds, GTA and Tourico, switches like Pegasus, and of course the GDSs).

So far, not necessarily scary, until you consider the interconnected nature of travel shopping

• As users search ever more and ever more casually (say on a mobile just to see what prices look like, or first on a mobile then at a work computer and then on home tablet), distributors face millions of people shopping for prices and availabilities.
• Distributors in turn ask wholesaler and direct providers, which in turn monitor one another, creating a gigantic echo chamber.

This would not be so bad if the need was just to cache prices for a reasonably static product at Amazon. But the need in travel is to maintain an heterogeneous system with intense read/write loads so that you can simultaneously:

• Check your own data for price and availability.
• Request data from switches, wholesalers and primary providers such as hotels or airlines.
• Explore CRM angles if you can identify the shopper as a prior customer.
• Explore personalization, retargeting, and cohort optimization whether you can identify the shopper or not.
• Revenue optimize sort order and other aspects of how you respond to a search.

Hospitality details: How does this translate into costs?

In some cases of lesser efficiency with traditional technologies, we find the direct cost of a search can be as high as 9 thousandths of a cent ($0.00009).

• In this definition “direct” means all costs for an additional quantum of searches – hardware, software, bandwidth and people, but excluding SG&A and other relatively static costs.
• While 9 thousandths of a cent per search may sound high when pro-rated over the entire universe sub-searches, basic math with pro-rated costs can get you there: add the physical layer costs, network/bandwidth, software license costs, variable human input costs, and third party costs that may come into play for some subset of the searches.

Now let’s check how many searches have to happen before a traveler books…

• You may recall it’s not unusual for a large wholesaler to see 7,500:1 look-to-book ratios that metastesize into 150,000:1 search-to-book ratios.
• That would mean 150,000 * $0.00009, or $13.50 per booking when calculated over all local cache searches and related "pull" searches.  An alternative calculation would be to look at cost per inbound search (excluding metatstesized pulls).  That would mean 7,500 * $0.0018... also equal to $13.50 per booking.
• On a booking for a single night at $80, with a margin of let’s say 15%, that would mean that the margin of $12 would NOT cover the direct search costs.
• This might be a corner case, so let’s consider hotel industry typical numbers of something like 2.4 nights per stay and $150 average daily rate. Assuming a 15% margin that means $54 per booking to play with.
• Reversing direction now, we can ask, what look-to-book ratio would cause a channel to be unprofitable? Any channels that exceed 600,000 total searches including pulls per booking would be operating at a loss.  For those who prefer to look ratios based on inbound searches instead, this would mean that any channels exceeding 30,000 total searches per booking would be operating at a complete loss... even on high relatively higher value hotel bookings.

Airline use cases are also hairy

Airfare price and availability searches are also a challenge. Imagine that you want to handle both sudden peaks in demand and broad queries over many alternative dates.

• As mentioned above, the computational challenge here is to solve a “traveling salesman” style problem, with costs associated with each graph segment and in fact each combination of segments.
• There are a number of services that can handle a fairly simple search. Global Distribution Systems have been doing it for years, and often serve not only in their legacy capacity of answering travel agent queries, but also as API providers. When acting as API providers, costs per search vary, but let’s say they might hover around $0.03 per search for your average small client.
• The main alternative to GDS APIs has been ITA Software, which provides more sophisticated and arguably more cost effective searches now that they’re under Google… let’s say something around $0.02 per search depending on volumes. Emerging challenges come from startups such as Vayant, which use modern technology offer data more cost effectively.
• But now let’s see what an innocent price calendar for air fare might imply: Say you want to show shoppers a 90 day calendar, where they can see the best price for departing on any given day and returning on any of the subsequent days up to 15 days later.
  • There are ~90 possible departure dates and each one could be pared up with 15 possibly different return dates (basically covering an overnight trip all the way to a two week vacation). So that’s 1,350 searches to build a calendar of prices.
  • So far so good, except that look-to-book ratios for air distributors can be somewhere between 500:1 and 1,000:1. These can be even higher for B2B API providers such as GDSs, ITA Software and Vayant.
  • Suppose then this interesting challenge: build 90 day custom calendars with look–to-books of 500:1 and 1,350 queries each and suppose that every time one person books the price or availability or both may change.
  • Now suppose that determining “best” really means exploring all relevant and acceptable costs of getting from A to B with any possible layover in between. No surprise then that costs can be on the order of $0.02 per individual visitor search, with look-to-book ratios of 500:1 and live user searches per visit of 4.
  • In this extreme this would net to effective costs of as much as $40.00.   Which doesn't sound that earth-shaking... until you consider that most U.S. domestic air tickets don’t have $40.00 or margin to spare.

It’s here that something like Aerospike can really make a difference

• Typical arrangements with legacy technologies would scale at a rate of about one additional server for each peak of about 500 searches/second.
• At first this might ridiculously low throughput, but we have observed this in practice, often when traditional RDBMSs are involved so that record locks and other code-level latency inducing issues gate high performance for simultaneous reads and writes.

On the other hand, with Aerospike:

• An individual server easily reaches and sustains about 1 million reads/sec in RAM, with latency tolerances such that 99% of all reads return within less than a millisecond. Only other solution in RAM that’s worth mentioning is Couchbase, which in-memory only can actually step up to Aerospike. But since independent tests show it flails miserably for data sets too large to hold entirely in RAM, Couchbase is rather limited and limiting unless you can restrict your data set or you're prepared to pay for large clusters with immense amounts of RAM.
• For balanced read/write scenarios (needed in travel where price and availability are subject to change all the time) Aerospike has been tested at well over 50,000 transactions per second per server using SSDs.
• Versus a legacy solution of similar costs, the price/performance advantage is on the order of 100 times better.
• Versus MongoDB and Cassandra, Aerospike has been independently tested to a 10X performance advantage together with a hardware cost advantage ranging from 4X to 14X using SSDs.

For those whose ambitions are to perform travel related searches at unremarkable speeds and user numbers, we say, cool, shard Postgres and use Couchbase as a cache and go forward. You’ll do just fine.

If your data set is small enough now and for all foreseeable growth in the future that in can all fit in RAM, you can use either Aerospike or Couchbase… both are quite good with in-memory data sets.

But if you’re shooting for remarkable speeds with Internet scale transactions and hot analytics over large data sets, there’s no substitute

• Aerospike is the first product to totally transform what you can expect from an affordable, and now open source, technology.
• It gives you speeds you thought could only come from RAM at flash SSD economics.
• It scales both in speed, data size and use cases: it can operate in-memory, on directly addressable flash, as a hybrid and on disk as well.

###

N.B.: The author holds a minor equity stake in Aerospike and personally suffered through trying to scale other solutions in metasearch, hotel bookings and revenue optimization/personalization technologies