An essay in the system design of SignIn workflows. 

Most web applications require to authenticate a user via signing in. Such applications of all sizes usually delegate the task to a membership provider which takes different forms. We talk about some of these manifestations and their pros and cons. The task inherently may involve something as simple as looking up a user account in the database, or looking it up in the Active Directory or looking it up using API calls for industry accepted authentication and authorization protocols

Fundamentally the account is needed for a session on the application so that the user can seamlessly visit one or more pages without having to authenticate on each page.  When the identity is linked to an account that spans one or more business, then the notion of a single user account is lost and we involve a pool of accounts all pertaining to the same user.

User account when stored and indexed is easy to lookup and results in faster retrieval. Social engineering applications use a mix of relational as well as NoSQL stores for the purposes of storing accounts and their resources respectively. Typically they have a sql connector over their NoSQL so the querying can be expressed in the same language. They need to store user resources such as chat, images and logs in big data because the volume is large and data processing is batch oriented. With user accounts, even the logs are interesting for audit purposes and consequently important to store.

SignIn Applications can be categorized as front-end oriented, middle-tier motivated or back-end performance driven although they may use all three to some degree. When these applications are front-end oriented, we often see the use of Model-View-Controller kind of patterns that evolve to include viewmodels. Since there are re-usable parts of workflows for signin across applications like registering, login, password retrieval, using one-time passcodes, verifying with the help of email or phone and many  more, they often take the shape of widgets where workflows are described in the form of widgets which can be composed or standalone.  Front-end heavy applications pay special attention to consistency and user experience across different use cases.

Middletier motivated applications can be recognized by their dependencies on services or service oriented architecture to be precise. Every task small or big is now a service call away and may exist even behind a gateway or an information bus. These applications were earlier designed with a hierarchy of individual services organized in object-oriented terms while each retaining its independence with its own address binding and contract definitions. More recently, this organization has become flat, fine grained and with the notion of microservices and perhaps serverless computing. When services are involved, applications tend to bring standard enterprise practices such as those describe by the enterprise application blocks where logging and metrics are part of the service implementations. Services also enable independence from data store concerns which brings us to the third category.

Indeed some of the sign-in applications especially for web-applications implemented using well known frameworks make use of data stores in the form of membership providers where the store itself performs search and retrieval using a standard interface that web-application frameworks expect. This has made it convenient for the application to reduce its footprint of signin logic so that the data is kept organized and there is little code involved. Such stores come with the benefit of being the single source of truth at any time.

Thus we see that there are different forms of SignInApplications and their implementations.

#puzzle
How many positive five-digit integers are there consisting of the digits 1, 2, 3, 4, 5, 6, 7, 8, 9, in which one digit appears once and two digits appear twice? For example, 41174 is one such number, while 75355 is not.
If one number appears once, it can be chosen in 9Choose1 ways.
The other two digits that appear twice can be chosen in 8Choose2 ways.
The number of permutations of these selections is given by
permutations based on number of digits  divided by permutations based on repetitions

= 5! / (2!2!1!) = 30

Therefore the total number of numbers is 9Choose1 x 8Choose2 x 30 = 7560 possible numbers that satisfy the given criteria