I’m going to become an erlang ninja. So rewriting some of my old ruby code that could use some parallelizing seems like a good way to start. I’ll start with a description of what the project is and why I think erlang would do a better job than ruby and then I’ll set out to prove myself right!
Mail Sentry (Ruby Version)
Years ago I had a grand vision of an email analysis system for hospitals that would scan all outbound emails for patient health information or other sensitive data. The system could be configured to block offending mail and notify the privacy office or force the message through a challenge response process that forces the receiver to view it over a secure connection rather than allow the message to be sent unsecured.
So I built it using Ruby. It’s never seen any “real world” action, but it works. The gist of it is this:
You take all the sensitive data you have (patients name, addresses, medical record numbers, etc) and it’s tokenized and hashed and loaded into an in memory DB.
There is a message analyzer that’s added as a filter on your organization’s mail relay (to sendmail, zmailer, whatever). It rips apart the message and converts binary attachments into tokenized text (pdf, word, etc. It can even do OCR on scanned images). It’s passed off to a DRB service that hosts the in-memory DB of hashed sensitive data.
The assumption is that if you have a list of just the first name of 100 patients/clients/whatever, then you aren’t actually violating anyone’s privacy because you haven’t uniquely identified any specific patient. So the DRB service builds a list of hits against specific patients/entities. For example, it determines that a patient 1 had their first name referenced, patient 2 had their last name referenced, patient 3 had their first, last and social security number referenced.
Those “hits” are passed to a rules engine that allows each institution to define what constitutes a breach of privacy. Pretty much anyone would agree that patient 3 in the example above is enough info to uniquely identify them. The rules also specify the action (allow, deny, log, notify, etc) to perform.
The erlang re-write
This all works great. So.. why re-write it in Erlang?
Well, we have many processes (managed by the mail relay) generating analysis requests, but only 1 DRB service to manage them. If we want to scale beyond a certain point it’ll get rough.
So, here’s the plan: Let’s rewrite the “Message Analyzer” as an erlang server. The ruby is working perfectly for ripping apart the email, running the rules engine, converting the attachments and so on.. so let’s leave it as Ruby.
If it all works out, we should have a super scalable email analysis tool that can scale to any sized organization, with any amount of sensitive data.