PID generator

Requirements

Let's begin with some context! Within the world of real estate each property is assigned its own unique ‘property identification number’, or ‘PID number’ for short. Detached, single-family homes have one, duplexes have a couple and in the case of apartments, each unit has its own separate PID.

The challenge arises when agents wish to add their new property to the central MLS system but a PID number hasn’t yet been assigned. It’s not possible to create a listing without one, so, suddenly: here’s a stumbling block.

For a long time the solution has been to hand out ‘fake’ PIDs to agents, ones they can use in place of the actual PID until the real one has been issued. These fake PIDs occupy a certain range so they can easily be identified at a later date.

For at least a decade we’ve had a basic internal web app allowing staff to generate these fake PIDs. However, in the course of this app being migrated to a new server, it partially broke — suddenly going from issuing up to nine PIDs at a time to only one. Compounding this issue was the original source code having been misplaced and lost many years prior. The only path forward was to build a new solution from scratch.

As such, the primary requirements can really be summed up in two parts: the obvious need to re-create the PID generator as a modern service, but also to design it in a way that our members would be able to use it themselves. This last part was key — it would remove the necessity of them calling staff each and every time they found themselves in need, thus reducing the amount of time spent dealing with this on a day-to-day basis.

Process

This project overlapped entirely with the much larger work of us changing CRM system, moving from a slightly dated on-premises solution to a modern one located in Azure (Microsoft Dynamics). Despite this progressive move, the majority of the new integration points were still set to run through the on-premises data centre. This struck me as vaguely anachronistic and became part of my motivation to ensure this PID generator project would be entirely cloud-native — the organisation’s first in its entirety.

My chosen infrastructure became:

  • Azure Blob Storage for the frontend. Microsoft also offer the ‘Azure Static Web Apps’ service (capable of auto-publishing any new commits made to a git repository, à la Netlify) but this offering was still in preview status at the time and they were discouraging its use in production environments.
  • Azure Functions for the backend — the prime job being to communicate with the database and perform validation. Azure Functions supports a variety of languages but I chose C# for a couple of reasons: it’s generally favoured by the organisation, but it also has the fastest cold boot times out of all the supported languages. (I had come across someone’s comprehensive write-up extensively comparing cold boot times for each Azure Functions language.)
  • Azure Cosmos DB for the database. Someone pointed out to me that a distributed database was a strange choice for what would be essentially the sole task of incrementing consecutive IDs, but the main motivation here was Microsoft having recently enabled serverless billing. (An alternative to their traditional model, which has always required a base level of throughput to be reserved and paid for.) This meant a free tier for the Cosmos DB service, a vast reduction in cost compared with the other billing model. The PID generator has always been a relatively low priority service, so being able to guarantee zero costs was a great bonus.

Last but not least, Vue was my choice of framework for the frontend, despite the small scale of the app. This decision was partly based on wanting to simplify the handling of incoming PIDs as much as possible, but also because it seemed like a good opportunity to familiarise myself more with Vue.

Challenges

Composing the backend logic definitely took longer than I’d anticipated, mostly because I hadn’t expected the Azure Function to need to perform an atomic read-write on the database. It’s imperative that members don't receive the same PID as someone else, so the database must finish reading, incrementing and writing the new value prior to allowing anyone else to read it.

This simply isn’t possible with the .NET SDK — because Cosmos DB isn’t designed to work this way. Nevertheless, the promise of zero costs meant I wasn’t deterred for very long, and I ended up writing a stored procedure within the database’s JavaScript environment. This also provided an unexpected benefit: the read-write was now computationally cheaper than it would’ve been otherwise. For a web app with such low traffic this won’t result in any real-world differences, but I view it as valuable knowledge for future projects; at a larger scale it could result in significant cost savings.

Future improvements

Some functionality discussed initially but ultimately rejected was to keep a record of which agent had been issued with which PID. While this would have been informative, in the end there wasn't really a strong enough reason for the data to be retained. If greater accountability of the PIDs were deemed to be a priority in the future though, this would be a good place to start.