Applied Systems: Recommenders, Cryptography, Scale, and Responsibility

Study notes I'm keeping as I learn to program. The ideas here come from Imran Ahmad's 50 Algorithms Every Programmer Should Know — I'm sharing them in my own words. The plain-language explanations, the examples, and any mistakes are mine.

The concept in plain language

This is the part of the book where the ideas leave the whiteboard and hit the real world — the messy engineering of getting software to recommend, store, protect, scale, and behave itself.

Start with recommendation engines, the software that guesses what you’ll want next. There are two basic recipes. Content-based filtering says “you liked this thing, here’s another thing with similar features.” Collaborative filtering ignores the features entirely and looks at behavior: “people who acted like you also liked X.” Most real systems are hybrid — they blend both. The classic headache is the cold-start problem: a brand-new user or a brand-new item has no history, so the system has nothing to reason from. It’s the recommender equivalent of a new patient with no chart.

Next, data handling — the unglamorous plumbing of storing, governing, and shrinking data. Compression is the standout trick. Huffman coding, an algorithm David Huffman worked out as an MIT term paper in 1951 and published in 1952, gives frequent symbols short codes and rare ones long codes, squeezing files with zero loss. It still lives inside ZIP archives and JPEG photos today.

Then cryptography, the math that makes secrets possible over an open wire. Symmetric encryption uses one shared key for locking and unlocking — fast, but both sides need the same secret. Asymmetric (public-key) encryption uses a pair: a public key anyone can use to lock, and a private key only you can use to unlock. Hashing is different again — a one-way fingerprint of data. A good hash should never produce the same fingerprint for two different inputs; when it does, that’s a collision, and it’s a security emergency.

Two ways to keep a secret over an open wire. Symmetric: one shared key (fast, but you must exchange it safely). Asymmetric: a public key locks, a private key unlocks — the idea behind the padlock in your browser.

Then scale. Amdahl’s law, stated by Gene Amdahl in 1967, is the cold shower of parallel computing: if part of a job must run in sequence, that serial part caps your maximum speedup no matter how many processors you throw at it. Per the standard formulation, a task that’s 10% inherently serial can never go more than 10 times faster. GPUs (graphics chips repurposed for math) and tools like Apache Spark push against that ceiling by doing enormous amounts of work in parallel.

Amdahl's law. More processors help less and less: the part that must run in sequence sets a hard ceiling. A 90%-parallel job can never beat 10×, no matter the hardware.

Finally, responsibility: explainability (can you say why the model decided that?), bias (does it treat groups unfairly?), and NP-hard problems (a class of problems for which no known algorithm finds the perfect answer quickly, so we settle for good-enough).

Where you’ve seen it in the real world

The Netflix Prize is the recommender legend. From 2006 to 2009, Netflix offered $1 million to anyone who could beat its Cinematch algorithm by 10% on rating-prediction accuracy (RMSE). A stitched-together ensemble of over 100 models finally won. The twist: Netflix’s own 2012 engineering blog explained that the full winning ensemble was never put into production — the accuracy gain didn’t justify the engineering cost, and the business had already moved from DVD ratings to streaming behavior. Meanwhile the workhorse that actually scaled was Amazon’s item-to-item collaborative filtering, described by Linden, Smith, and York in IEEE Internet Computing in 2003 — the “customers who bought this also bought” engine.

Cryptography is running right now in your browser. Every HTTPS padlock rests on public-key ideas from Diffie and Hellman’s 1976 “New Directions in Cryptography” and the RSA algorithm that followed in 1977–78. And broken hashes are not theoretical: researchers led by Xiaoyun Wang demonstrated full MD5 collisions in 2004, and in 2012 the Flame espionage malware exploited exactly that weakness to forge a Microsoft code-signing certificate, letting it masquerade as a legitimate Windows update.

Scale shows up in modern AI itself: the 2012 AlexNet result by Krizhevsky, Sutskever, and Hinton crushed the ImageNet image-recognition benchmark, and it did so by training a deep network on GPUs — the moment that lit the fuse on today’s deep-learning era.

Responsibility has its own hall of infamy. ProPublica’s 2016 Machine Bias investigation found that the COMPAS criminal-risk tool wrongly flagged Black defendants as future re-offenders at nearly twice the rate of white defendants. And in 2018, Reuters reported that Amazon scrapped an experimental recruiting tool after it taught itself to penalize résumés containing the word “women’s” — the model had learned bias straight from a decade of mostly-male hiring data.

The healthcare angle

For a physician, these abstractions have blood pressure.

Encryption is the difference between a HIPAA safeguard and a breach. The HHS HIPAA Security Rule treats encryption of electronic protected health information — both at rest on disk and in transit across the network — as a core safeguard for keeping patient data confidential. When broken cryptography meets clinical systems, the result is not abstract: the 2017 WannaCry ransomware worm swept through the NHS, and the UK National Audit Office later reported roughly 19,000 cancelled appointments and an estimated £92 million in total cost. Cancelled appointments are delayed diagnoses.

Bias in a care algorithm is a clinical harm. The most sobering example is Obermeyer and colleagues in Science in 2019. A widely used population-health algorithm decided who got extra care management — but it used past healthcare spending as a stand-in for health need. Because less money had historically been spent on Black patients at the same level of illness, the model systematically judged them healthier than they were. The authors calculated that fixing the proxy would raise the share of Black patients flagged for extra help from about 17.7% to 46.5%. Same data, wrong target variable, real patients left out.

And the tide of data is only rising. The cost of sequencing a human genome has fallen off a cliff — the NHGRI’s cost-per-genome data shows a drop from roughly $100 million in 2001 to a few hundred dollars, outpacing even Moore’s law. Cheaper genomes mean more genomic data flooding into medicine, which loops right back to storage, governance, and encryption.

Why it matters when you work with AI

If you take one lesson from this part of the book, make it this: an accurate model is not the same as a usable, safe, or fair one. Netflix proved a champion algorithm can be too costly to ship. Amazon and COMPAS proved a confident model can be confidently unjust. Obermeyer proved that the thing you optimize for — cost versus need — can quietly encode discrimination even when nobody intends it.

So when you evaluate any clinical AI, ask the questions this chapter arms you with:

What is it actually optimizing? A proxy like cost or prior utilization can smuggle in bias, as the Science study showed.
Can it explain itself? An unexplainable score is hard to challenge at the bedside.
Was it tested across the groups you serve? Aggregate accuracy hides subgroup harm.
Is the data protected end to end? Encryption and sound key management are patient safety, not just IT hygiene — WannaCry is the cautionary tale.
Where’s the cold-start blind spot? New patients and rare conditions are exactly where thin data makes models least trustworthy.

You don’t need to build these systems to interrogate them. Knowing how recommenders guess, how encryption holds, where parallelism hits its ceiling, and how bias sneaks in through the objective function is enough to be the person in the room who asks the question that keeps a patient safe.

Sources

About this series. These are study notes I'm keeping as I learn to program — I'm sharing the ideas, not claiming them. The concepts belong to 50 Algorithms Every Programmer Should Know, 2nd edition, by Imran Ahmad, Ph.D. (Packt Publishing) and its companion code repository, github.com/cloudanum/50Algorithms; the plain-language explanations, the real-world examples, and any mistakes are mine. No text is reproduced from the book, and this series is not affiliated with or endorsed by the author or Packt. If these ideas are useful to you, buy the book — it goes far deeper, with working Python for every algorithm. Where a case study leans on a third-party explainer (for example, Jay Alammar's The Illustrated Transformer or Chris Olah's Understanding LSTM Networks), it is credited in that page's Sources.

— Jeremy Tabernero, MD · More in this series · Get in touch