Product
Content recognition
Finds where your content resurfaces online, including where it has been cropped, slowed down or re-uploaded.
| Kind | Product |
|---|---|
| Start | |
| Technology | Kubernetes, Kafka, KEDA, PostgreSQL, pgvector, ArgoCD |
| Worker ceiling | 72 |
| In service | 9monthsrunning |
In detail
Finding an unchanged copy is easy. The difficulty is in what has been altered: different tempo, different crop, recompressed. That is what this system is built for.
Processing runs over an event stream. How many workers are busy at once depends on how full the queue is, because the load arrives in bursts; 72 at most. It runs on hardware we set up and maintain ourselves.
This is our own product. We build systems like it for other people too.
The log for this system.
- Operations
Turned a real outage into alert rules, so the same failure is noticed next time before anyone phones about it.
- Data
Moved processing onto an event stream; autoscaling has followed queue depth since. Messages that fail three times run into a queue of their own and stay there for review.
- Operations
Built our own bare-metal Kubernetes cluster, because managed nodes would have cost more at this load profile.
Next step
We will tell you up front where the time will go.
Describe your plan in a few sentences. We will name the two or three places where a system of this kind turns expensive.