A yes/no question, answered by a crowd

Everyone has an opinion. The harder question is what a crowd actually thinks — and whether the answer holds up when you break it down by who gave it. Yacket asked that question in the simplest possible form: yes or no. Toobler built the platform that collected the answers and made them mean something.

Customer and context

Yacket was founded by Aaron Smith in Melbourne, Australia, out of the York Butter Factory co-working space. The idea was deliberately narrow: a question with exactly two answers, asked through Twitter, answered by whoever wanted to weigh in — and then analysed by demography, so the result was not just “62% said yes” but who the 62% were.

Toobler was the engineering partner for the whole of it. Not a team hired to build a screen someone else had specified: user experience, interface design, project management, web development and the cloud infrastructure underneath, delivered as one group.

The challenge

A product like this fails in two places, and neither is the part users see.

Signup could not wait on Twitter. When someone logged in with Twitter, Yacket needed their “following” list — the graph that makes demographic analysis possible. For an account following hundreds of people that is a slow call to someone else’s API, and doing it inline means the user sits on a spinner while a third party takes its time. Worse, if Twitter is slow or down, registration is slow or down with it.

A pivot changed the shape of a question. Customer feedback in 2012 asked for more than yes/no. Yacket added Battle, where the two answers are two Twitter users, and multi-option questions, where the asker defines the answers. Both changed the core data model of a product built around a binary.

The solution

Ingestion moved off the request path. Instead of fetching a new user’s following list while they waited, Toobler put the user’s ID and tokens onto an Amazon SQS queue at signup. A separate process consumes that queue, calls the Twitter API at its own pace, and writes the graph into RDS (MySQL) asynchronously. Registration returns immediately.

The queue is doing more work than it appears to. It decouples ingestion from the application, so a failure in the slow path cannot take down the fast one. It absorbs bursts — a spike in signups becomes a longer queue rather than a slower site. And because SQS retains messages for days, a consumer that falls over loses nothing. The architecture was designed to scale horizontally from the start, so capacity followed usage rather than being provisioned for a peak that might not come.

The stack was chosen for pace, not novelty. PHP with CodeIgniter — picked for its documentation and community, and because its conventions suited an agile build where the product was still moving. The Twitter streaming API provided low-latency access to the tweet stream without the overhead of polling REST endpoints.

Engineering worth naming

• The slow dependency is the architecture. The interesting decision here was not which framework to use; it was recognising that a third-party API in the signup path is a reliability problem, and moving it behind a queue before it became one.
• A pivot the data model had to survive. Going from “two answers” to “two Twitter users” to “answers you define” is three different shapes for the same table. Shipping that on a live product is the part that does not appear in a screenshot.
• One team across the whole lifecycle. Design, front end, back end, delivery management and infrastructure in the same group — which is what the client’s own account of the engagement emphasises.

Results

Yacket reached public beta as a working product: Twitter-authenticated, collecting yes/no and multi-option answers, presenting them as demographic breakdowns, and running on infrastructure built to grow.

Adoption and volume figures are the client’s to publish, and are not estimated here. What stands is the scope — a complete product, from the question a user types to the queue that keeps the site responsive while someone else’s API catches up.

What this means for consumer platforms today

The stack has moved on; the failure it avoided has not. Any product that authenticates through someone else’s service and then needs data from it faces the same choice at signup: block the user, or accept the data eventually and get out of their way. Queue-and-consume is the older answer and it is still the right one — it is why a slow partner API degrades a feature rather than the front door.

The other lesson is about the shape of the team. The commercial reason this project moved quickly was not a technology choice; it was that design, delivery and infrastructure sat together, so a question about a queue did not need a meeting between three vendors to answer.