The context
PearTV is an internal product, designed and funded by Wisepear techlab. It is not a client engagement: it is our proving ground, and the project where we stress-test at scale the architectural choices we then propose elsewhere.
A complete streaming platform: content aggregation, enriched catalogue, recommendations, and applications for mobile, connected TV and web.
The challenge
A streaming service raises problems you never meet on a conventional business application.
The catalogue is never stable. Content comes from more than forty different sources, each with its own format, reliability and outages. A source that changes structure overnight must not bring down the entire catalogue.
Metadata makes the product. A catalogue without artwork, synopses or coherent genres is unusable, however good the streams are. Enrichment and deduplication account for a considerable share of the system.
Three surfaces, three ergonomics. A television application is driven by remote control, three metres from the screen, without comfortable keyboard input. It is not an enlarged version of the mobile app: it is a separate design that nevertheless has to sit on the same API.
What we did
- A Django back-end carrying the catalogue, aggregation, metadata enrichment and personalisation, exposed as a REST API shared by every client.
- Fault-tolerant collection, with each source isolated: a failing source degrades its own scope, never the service.
- An Android application and a connected-TV application, designed separately for their respective constraints, on the same API.
- A web interface completing the set.
- Running the service over time — it is by operating a product ourselves for four years that you learn what is expensive to maintain, and what not to propose to a client.
The outcome
A finished product, developed over four years, with more than seven hundred combined releases across the back-end and the applications.
What PearTV gives us is hard to fit on a brochure, but shows up in client work: we have designed, delivered and then operated a distributed system over the long run. So we know what an architecture costs once it is in production — not only what it promises on paper.
It is also where our reflexes about systems depending on external sources come from: isolate, degrade gracefully, and never let an outside failure become an outage the user can see.
Screenshots
