How Unbxd Uses Route 53 to Provide Search API’s to Your Site Search

Before we started using Amazon’s Route 53 service, for every new sign up we had to manually go create a sub domain for each customer to provide search API’s. This required a longer sign up and integration cycle as we had to go to our cPanel and manually add a sub domain name for each client. With Amazon Route 53, for every sign up for Unbxd Search, we automatically create a sub-domain and automatically should be APIs are published for the user. Using Route 53 removed the manual intervention required for on-boarding a customer. It also enabled out customer to begin testing search soon than our earlier approach. Finally, once they are done tweaking the search configuration through the dashboard to meet their business rules, they can begin integration of Unbxd search into their e-commerce site search box.
The below diagram explains how Unbxd Search is consumed by the end user:
Search Flow for using Unbxd Search API
The ability to create a DNS record on the fly through your application automatically is extremely useful. Managing infrastructure using APIs within your application becomes a powerful feature as it takes out any manual intervention needed on our behalf for the end-user to use the service.
I will describe briefly on the advantages of going with Route 53 as a domain name service and how we utilize it.
Route 53 lets you create a hosted zone which represents a collection of resource record sets under a domain name, our case the domain name being unbxdapi.com. Route 53 supports a wide variety of DNS resource record types. We typically create A Records to point it to our search load balancer.
The real power of Route 53 is in creating a record set where a Routing Policy can be defined.
Route 53 provides three routing policy options, namely:

Simple

Weighted Average

Latency Based Routing

Typical scenarios where weighted resource record sets could be used are:

DNS level load balancing

Live A/B testing of newly deployed code. One could assign a really small weight to a record set entry and thereby see a small percentage of it’s users directed to the cluster. Traffic vs performance could be monitored until one is sufficiently confident to migrate completely to the new version of code.

With the latency based routing one actually can control scenarios. For instance, let’s say a request originates from India and we would like that request to be served from the AWS APAC region compute servers. This can be achieved by “configuring two or more latency based record sets with matching names and types, then the Route 53 name servers will use network latency and DNS telemetry to choose the best record set to return for any given query.”
If you want to dig deeper into Route 53 resource sets and their routing policies, here are the links to the official documentation:
Resource Record SetsWeighted Resource Record SetsLatency Resource Record Sets
What would really interest me is a combination of both policies. A scenario where I want all my Europe-based visitors to be redirected to the new version of code. I’m not sure if this sort of use case could be supported by Route 53 or if Amazon is planning on implementing this feature.
I’ll end by saying that Route 53 is a very good service for automating the creation of your infrastructure management through a simple API.
I would be more than happy to hear your suggestions and comments on this post. You can also contact me at varun [AT] unbxd.com or tweet me at @varunthacker