A few notes:
- Polling every second is overkill. The app will still feel very responsive with a few seconds of delay between checks.
- To save your db’s traffic and speed responses, consider using an in memory cache to store undelivered messages. You could still persist messages to the db, the in memory cache would simply be used for queries for new messages to avoid queries to the db every x seconds by each user.
- Timeout the user’s chat after x seconds of inactivity to stop polling to your server. This assures someone leaving a window open won’t continue to generate traffic. Offer a simple “Still there? Continue chatting.” link for sessions that timeout and warn the user before the timeout so they can extend the timeout.
- I’d suggest starting out with polling rather than comet/long polling/sockets. Polling is simple to build and support and will likely scale just fine in the short-term. If you get a lot of traffic you can throw hardware and a load balancer at the problem to scale. The entire web is based on polling – polling most certainly scales. There’s a point where the complexity of alternatives like comet/long polling/etc make sense, but you need a lot of traffic before the extra development time/complexity are justified.