About
Farolan Faisal
I work on backend and data systems, and most of what I am hired for is a version of the same question: something is slow, or something is wrong, and nobody can say which. The useful part of the job is turning that into a measurement.
In practice that is mostly PostgreSQL — query plans, index design, the difference between what a statement looks like and what the planner is asked to do — sitting inside larger systems that have to keep running while it is fixed. Rails applications over deep schemas, services where one request fans out into hundreds of statements, billing and webhooks where being wrong is expensive in a way that being slow is not.
How I work
Two habits run through everything on this site.
The first is that a change is not done when the code is written; it is done when the behaviour has been observed. Every performance number here comes out of a benchmark that boots its own database, seeds it deterministically, and asserts that the two arms return the same rows before it reports a ratio. A rewrite that is fast because it answers a different question is not an optimisation, and the check exists because that failure is easy to ship and hard to notice.
The second is that the dangerous bugs are usually not crashes. They are states that render as healthy: a failed read shown as an empty list, a dead worker shown as one that is trying, a query that touches nothing reported as one that succeeded. Nothing throws, so nothing alerts. A lot of the writing here is about finding those and making them loud.
Working together
I take on contract work, usually one problem at a time rather than a standing team seat. The engagements that go well start with a specific symptom and a system I can measure — a slow endpoint, a queue that backs up, a bill that does not match.
If you have something like that, email me at hello@farol.dev with what it is doing and what you have already tried. I will tell you honestly whether it looks like something I can help with.