advertise
« Paper: Understanding and Building High Availability/Load Balanced Clusters | Main | Paper: Architecture of a Highly Scalable NIO-Based Server »
Monday
Oct082007

Lessons from Pownce - The Early Years

Pownce is a new social messaging application competing micromessage to micromessage with the likes of Twitter and Jaiku. Still in closed beta, Pownce has generously shared some of what they've learned so far. Like going to a barrel tasting of a young wine and then tasting the same wine after some aging, I think what will be really interesting is to follow Pownce and compare the Pownce of today with the Pownce of tomorrow, after a few years spent in the barrel. What lessons lie in wait for Pownce as they grow?

Site: http://www.pownce.com

Information Sources

  • Pownce Lessons Learned - FOWA 2007
  • Scoble on Twitter vs Pownce
  • Founder Leah Culver's Blog

    The Platform

  • Python
  • Django for the website framework
  • Amazon's S3 for file storage.
  • Adobe AIR (Adobe Integrated Runtime) for desktop application
  • Memcached
  • Available on Facebook
  • Timeplot for charts and graphs.

    The Stats

  • Developed in 4 months and went to an invite-only launch in June.
  • Began as Leah's hobby project and then it snowballed into a real horse with the addition of Digg's Daniel Burka and Kevin Rose.
  • Small 4 person team with one website developer.
  • Self funded.
  • One MySQL database.
  • Features include:
    - Short messaging, invites for events, links, file sharing (you can attach mp3s to messages, for example).
    - You can limit usage to a specific subset of friends and friends can be grouped in sets. So you can send your mp3 to a specific group of friends.
    - It does not have an SMS gateway, IM gateway, or an API.

    The Architecture

  • Chose Django because it had an active community, good documentation, good readability, it is open to growth, and auto generated administration.
  • Chose S3 because it minimized maintenance and was inexpensive. It has been reliable for them.
  • Chose AIR because it had a lot of good buzz, ease of development, creates a nice UI, and is cross platform.
  • Database has been the main bottleneck. Attack and fix slow queries.
  • Static pages, objects, and lists are cached using memcached.
  • Queuing is used to defer more complex work, like sending notes, until later.
  • Use pagination and a good UI to limit the amount of work performed.
  • Good indexing helped improve the performance for friend searching.
  • In a social site:
    - Make it easy to create and destroy relationships.
    - Friend relationships are the most important information to display correctly because people really care about it.
    - Friends in the online world have real-world effects.
  • Features are "biased" for scalability
    - You must get an invite from someone on already on Pownce.
    - Invites are limited to their data center's ability to keep up with the added load. Blindly uploading address books can bring on new users exponentially. Limiting that unnatural growth is a good idea.
  • Their feature set will expand but they aren't ready to commit to an API yet.
  • Revenue model: ads between posts.

    Lessons Learned

  • The four big lessons they've experienced so far are:
    - Think about technology choices.
    - Do a lot with a little.
    - Be kind to your database.
    - Expect anything.
  • Have a small dedicated team where people handle multiple jobs.
  • Use open source. There's lots of it, it's free, and there's a lot of good help.
  • Use your resources. Learn from website doc, use IRC, network, participate in communities and knowledge exchange.
  • Shed work off the database by making sure that complex features are really needed before implementing them.
  • Cultivate a prepared mind. Expect the unexpected and respond quickly to the inevitable problems.
  • Use version control and make backups.
  • Maintain a lot of performance related stats.
  • Don't promise users a deadline because you just might not make it.
  • Commune with your community. I especially like this one and I wish it was done more often. I hope this attitude can survive growth.
    - Let them know what you are working on and about new features and bug fixes.
    - Respond personally to individual bug creators.
  • Take a look at your framework's automatically generated queries. They might suck.
  • A sexy UI and a good buzz marketing campaign can get you a lot of users.

    Related Articles

  • Scaling Twitter: Making Twitter 10000 Percent Faster.
  • Reader Comments (7)

    How often did you spell Pownce wrong in this article?

    November 29, 1990 | Unregistered CommenterEdward O'Connor

    Love the site. Noticed you misspelled Pownce in the title of your post. Should be Pownce not Pounce.

    David

    November 29, 1990 | Unregistered CommenterDavid Cancel

    > How often did you spell Pownce wrong in this article?

    Oh, enough to look really stupid. On the plus side it did spell check :-)

    November 29, 1990 | Unregistered CommenterTodd Hoff

    Please don't let this site decline into another Web 2.0 circle-jerk. I see little of interest about Pownce -- everything mentioned is de rigueur these days. Can we have more articles about sites with real scaling issues, novel solutions, and interesting learnings?

    November 29, 1990 | Unregistered CommenterDevin Ben-Hur

    apologies in advance, but I've heard about enough about pownce ... learning anything from it is just over the top. the only thing pownce teaches anyone is that if you're well-connected, you can get the hype machine rolling for any piece of junk. wow, I would never have imagined that. that's surely never happened before in silicon valley.

    - 4 people is not a small team. A heck of lot more real software than pownce can be built with a 4-person team.

    - Use open source. There's lots of it, it's free, and there's a lot of good help.
    Sure. What closed-source tech did they look at? how much would it have cost? what benefits might it have provided? Or maybe you just want to pat yourself on the back. Some more.

    - Use version control and make backups.
    Thanks. Did I tell you how amazing and brilliant you are?

    - Database has been the main bottleneck. Attack and fix slow queries.
    - Take a look at your framework's automatically generated queries. They might suck.
    Well, I guess this would be a big learning for me too if I were 24. Oh, sorry, I mean, 24 and clueless.

    Pownce wouldn't be remarkable even as a homework assignment at DeVry technical institue.
    It's just celebrity at work -- the Los Angelesification of Silicon Valley -- and the truth is there's nothing inherently wrong with that. Just don't confuse it with any kind of real software engineering.

    November 29, 1990 | Unregistered CommenterAnonymous

    As I alluded to in the intro, it will be interesting to see how they change and evolve over time. A few things that might be generally interesting: they went with a desktop component, which is rare these days; use of S3 from the start; customer centered focus; and a buzz machine any startup would die for. Technically maybe not so much yet, but the beginnings of things are the sweetest and I like capturing that startup zeitgeist.

    November 29, 1990 | Unregistered CommenterTodd Hoff

    > Take a look at your framework's automatically generated queries. They
    > might suck.

    Is that a dig at Ruby on Rails Active Record? ;)

    November 29, 1990 | Unregistered CommenterAnonymous

    PostPost a New Comment

    Enter your information below to add a new comment.
    Author Email (optional):
    Author URL (optional):
    Post:
     
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>