Notes — Behruz Avezmatov

Mask the data before the model, not after

2026-05-26T00:00:00Z

The task sounded simple: process work messages with a language model, but in a way where names, phone numbers and contract numbers never leak.

My first idea was wrong — instructively wrong.

What I wanted to do

Send the text to the model, get the answer, strip personal data from the answer. The scheme looks workable right up until one question: what already happened to the original text?

It left. After that you can clean whatever you like — the data is already outside the perimeter.

What actually works

Masking goes first:

message → Presidio → [NAME_1], [PHONE_1] → model → answer → substitute back

The model physically never sees the real values. It works with labels, and that does not stop it understanding the meaning.

What follows for the architecture

Since masking has to happen before the model call, it cannot be an output filter — its place is in the pipeline, before the most expensive step:

the gateway accepts the message and puts it in a queue;
the worker takes it, masks it, calls the local model;
substitution back returns the values into the finished answer.

I had to split the gateway from the worker: processing takes seconds, and holding an HTTP connection through it means hitting timeouts within the first dozen requests.

The check that catches a regression

Worker logs print the text at every step. If someone reorders things and masking slides past the model call, you see it immediately — a real phone number where a label should be.

Why a circle detector does not find bubbles

2026-05-04T00:00:00Z

A bubble is a circle. So find circles. That is what I thought for the first half-day.

In a textbook image HoughCircles finds circles. On real footage it either sees nothing or sees hundreds of circles where there are none, and threshold tuning does not get you out of it.

The catch

The detector looks for edges. And edges on a real frame are broken for three reasons at once:

uneven lighting — one corner is brighter than another, and a threshold that suits the left eats everything on the right;
bubbles are semi-transparent — the boundary is blurred, the brightness step is weak;
bubbles are small — a dozen pixels each, and noise is comparable to signal.

Tuning the detector is pointless here: it is doing its job correctly, it is just being handed an unusable image.

What helped

The frame matters more than the detector. Two operations before it do more than any thresholds.

CLAHE — contrast equalisation over local tiles rather than the whole frame. The dark corner becomes comparable to the light one, and a single threshold starts working everywhere.

clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8, 8))
gray = clahe.apply(gray)

Top-Hat — a morphological operation: the image minus its own opening. What remains is smaller than the structuring element and brighter than the background. Exactly our bubbles, without the large background and gradients.

kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (15, 15))
gray = cv2.morphologyEx(gray, cv2.MORPH_TOPHAT, kernel)

The lesson that carried over

When an algorithm "does not work", look at its input before its settings. Out of this grew a habit of dumping the intermediate image after every stage — you can see exactly where things fall apart instead of guessing.

A money transfer and a race between two requests

2026-02-10T00:00:00Z

A learning payment system, a transfer between accounts. The code reads like the problem statement:

if account.balance >= amount:
    account.balance -= amount
    target.balance += amount

Works, as long as there is one request.

Where it breaks

Two transfers arrive at once. Both read the balance — both pass the check. Both debit. The balance goes negative by the amount of the second transfer.

Easy to reproduce: two requests in a loop, and within a few iterations you see a negative number where one cannot exist.

What does not help

Checking after the debit. Narrows the window, does not close it: the race just becomes rarer, which means it will be caught in production instead.
A lock in the application. Works right up to the second process. And a second process appears the day the service goes behind a load balancer.

What does help

Let the database decide — it knows how. The row is locked for the duration of the transaction:

SELECT balance FROM accounts WHERE id = :id FOR UPDATE;

The second request waits on that row until the first finishes, and reads the new value. Plus a constraint in the schema as the last line of defence:

ALTER TABLE accounts ADD CONSTRAINT balance_non_negative CHECK (balance >= 0);

The check in the code stays: it gives a person a readable error instead of a database exception. But it cannot be relied on alone — it is a hint, not a guarantee.

What I took from it

A rule I now check first: if someone else's request can fit between a read and a write, one day it will.