Postmark

Email threat detection is usually presented as a classification problem, and classification is the part that demos well. The part that decides whether the tool is usable is what happens after the verdict: an analyst has to be able to ask why this message was flagged, where it came from, and what else arrived from the same place — and get an answer that holds up.

That reframes it as a backend problem. The model produces a label; the system has to store the evidence behind that label, keep it attributable, and serve it back fast enough that checking is cheaper than guessing.

FastAPI, with request handling async throughout. The work in this service is almost entirely waiting — on the classifier, on geolocation lookups, on the database. Threads would have spent most of their memory sitting idle; an event loop holds far more concurrent requests on the same box for the same reason.

PostgreSQL rather than SQLite, which is the opposite of the call I made on OrderFlow and made for the opposite reason. Forensic intelligence means concurrent writers appending evidence while analysts read across it, and that is precisely the workload SQLite's single-writer model is not built for.

My second job was not code. Six people on a fixed deadline fail on integration, not on features, so the schema, the access layer and the branch-and-review workflow existed before the parallel work started. Everyone built against a boundary that was already defined.

The repository is private, and it stays private. A hackathon submission is written to a deadline and the code shows it; publishing it to look productive would invite exactly the scrutiny it was never built to survive. The architecture is the part worth discussing, and I can walk anyone through it.

Hackathon scope means the evidence trail is append-only and unbounded. Retention, partitioning and a real index strategy are the first three things that would need to exist before anyone pointed live mail volume at it.

The boundary between the service and the classifier is the thinnest part. It should be an explicit interface with a contract test, so the model can be swapped, versioned, or run remotely without the API layer knowing — and so a prediction can be traced back to the exact model version that produced it.

Test coverage was written to protect the integration points, which was the right priority under a deadline and is not sufficient outside one.