Serverless: Data Layer

The following post is part of a series of articles chronicling my journey into serverless implementation via a sample Case Study using a minimal viable product (MVP). TL; DR the source code used for the implementation and instructions on how to run the app locally are on GitHub.

Coming from the relational database world, working with partition and indexes seems a bit unnatural at first. In a relational database world maintaining a de-normalized table at storage and using views, procedures, functions, etc … to normalize data s almost a necessity as it is important to maintain a single source truth.

However, with the dirt-cheap prices on non-relational databases and lack of things such as secondary indexes (foreign keys in relational database lingo) having duplicate data that later can be reconciled could be a viable option for storing and consuming data.

Azure Tables which is index-based (non-relational) storage works best for working with Azure Serverless functions as the bindings make it easier to get references for storage clients. Depending on the partition that is used the storage can also be sharded and scaled without efforts to accommodate for high/low data demand.

I have used two data tables(document stores) with different partitions for representing the data later of the application. The partition key will keep the documents apart so that in the multi cluster-based back-end system auto-scaling can optimize the system without sacrificing performance for existing users.

During the registration process, users will mostly interact with the User document store limiting the data footprint and access to only one document store. After a phone number is verified a separate document store SlideShow takes over the responsibility of storing and retrieval of photo feeds for users.

I have used a combination of system generated PIN and user’s phone number to serve as a unique identifier for the document stores as it allows for a better record location and authentication mechanism.