Case Study
iPhone Mobile communications Review
A focused architecture review for an iPhone chat backend — four scaling options, a recommendation, and a benchmarking plan the client ran himself.
Not every good engagement is a big one. This one was a single written report, and it did exactly what it needed to.
The engagement
A contractor was building the backend for an iPhone chat app — chat rooms, friend requests, the usual — in PHP and MySQL on AWS, and he was nervous about what would happen to chat latency as it scaled toward thousands of concurrent users. He didn't want a big retainer. He wanted a few hours of someone who'd seen this problem before.
So we scoped it tight: a written report on the message-queue portion of the server, plus an assessment of where latency would break under load.
What I did
The report laid out four approaches, ordered from least invasive to most. At one end, leave the polling in MySQL and tune around it. At the other, move to a real message broker over STOMP, which would take chat latency from seconds down to milliseconds. Each option got its pros, cons, and real-world specifics, with a clear recommendation — and I threw in a benchmarking methodology at no charge so he could run the load tests himself rather than take my word for it.
I also steered him away from over-engineering. He'd been eyeing XMPP and Comet/Bayeux; I pointed out that Comet exists for browsers that lack sockets, whereas a native iPhone app has sockets and can just speak a broker protocol directly. And when he sent me his actual chat query, I flagged the real problem: MySQL is bad at optimizing that kind of subquery, so either split it in two or rewrite it as an inner join.