In this Mobile Reference Architecture, smartphone and tablet needs are addressed. Latency, geo-availability, rapid feature iteration, redundancy, and resiliency are all key design points.
Redundancy and resiliency are managed at several tiers. Inbound requests arrive at the top of the diagram, through a Global Load Balancer on a StingRay appliance allocating traffic to multiple clusters of Node.js servers. These clusters host the actual application, and can be distributed across geographic locations if needed. An L4-7 load balancer with Nginx proxies provides functions like SSL termination and routing as needed, depending on the complexity of the underlying services. Simple services may only require load balancing and static content caching. More complex architectures may fragment the URL space across different functions and thus different servers, or may segregate high-value traffic (say a customer in shopping cart checkout) to dedicated servers.
Because end-user latency can be critical to the success of a mobile application, there are several ways to increase the responsiveness of a mobile backend. An in-memory key-value database like Redis can cache responses from a more complex persistence tier, like MongoDB. Of course Redis can also be backed by disk, which makes initial cache population on restart faster and clean restarts more responsive. Transactional data and data freshness in general need to be considered carefully in any caching tier.
In this Web Caching Reference Architecture, there are multiple ways to reduce perceived latency of a web or mobile application across geography, over slow queries or in spite of network delays. Caching is a mechanism to re-use or anticipate the efforts of a slow query or computation. A particular application may need caching of static web page components like images or stylesheets or it may benefit from the caching of an aggregation over a large dataset, like with a Map/Reduce computation.
At the top of the diagram, a distributed cluster of Riverbed StingRay appliances running on Joyent SmartOS form a Content Delivery Cloud (CDC) for locating relatively static content close to a geographically diverse user base. In this example, one cluster of the CDC is in US-centrally located (from a network perspective) Las Vegas. A second cluster is in Amsterdam, serving much of Europe. In advanced modes, the CDC endpoints can also optimize web content, compressing and removing redundant information in HTML and images.
Further down the stack, a pair of Node.js servers acts as origin servers, in conjunction with the Manta Object Storage Service as a content storage. For simple documents or images, the Node application can serve directly from the Object Store, tagging them with time-to-live caching directives and/or respond to freshness queries from remote CDC endpoints, saving on bandwidth and thus improving customer experiences.
In this architecture, more complex queries are served by a fulfillment app that leverages the Manta Compute Service for computing across a large number of datapoints. For example, a query for feature extraction of a famous face across all newsfeeds and videos could be run hourly, but results could be cached between hour-long runs in a succinct form in a NoSQL database like Cassandra. During the runs, the Node.js application would serve out of the Cassandra application cache, and when the data is stale, or a relatively minor celebrity is selected, a job request could be kicked off to the fulfillment app to return just a small number of queries at first, with follow-on results to be delivered as available.
Caching is a very powerful tool to help minimize the latency of an application. These are some of the ways that Joyent can help.
In this Production Analytics Architecture, production data from catalog SKU and customers, say product glossy images and sales transaction data, are addressed as well as server log analysis and Business Intelligence for customer behaviour analysis. Responsiveness in data transformation, data integrity, and rapid data warehouse analytics are the key design points.
Inbound customer requests arrive at the left top of the diagram, through load balanced Node.js server clusters, similar to the ones described in the Mobile Reference Architecture, but in this case Relational Databases are depicted as MySQL or Percona clusters running on Joyent SmartOS images. In these databases, business and e-commerce information is distributed across a shared cluster of MySQL instances for SKU retrieval and customer transaction storage.
Both raw server log information and user uploaded multimedia content are routed directly to the Manta Storage Service. These large unstructured data objects are organized into Manta's hierarchical folders, which can be used to shard customer data or multimedia information simply by partitioning folder space by customer code, or datestamp.
For the ever broadening array of tablet, smartphone and PC display form factors, a variety of image sizes can be generated directly on Manta using its supercomputing facilities, which spin up on demand and are billed by the second. Compact WebP images can be created and served directly from Manta's public folder space to save bandwidth and transmission time.