The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Web Application (Database backup woes, payment processing etc.)

Hi,
 I am developing a web app for the first time. This is how it is going to be:

1. Web App is developed in PHP, PEARDB, MYSQL.
2. It will be hosted on a shared web hosting server.

I have a few questions:

1. Is the above configuration sufficient for running a web-app to handle say 1000 users. When should I think of moving to a more "reliable" (if required) service? I don't want to spend money on that as I want to see how the idea  works out at the start.

2. The app will be handling user data related to their business. So I guess database backup is a MUST. Now who will actually do it? Is it the responsiblity of the hosting provider or is it me? If I have to do it, how do I do it? Do I daily download the database folder to my local machine and back it up? Please clarify this point.

3. How can I handle subscription payment? I don't want to setup a merchant account for now. Can I use payment service provides such as SWREG for this? Can I handle recurring payments through such providers?

4. Anything else you think that I may not know about running a free+paid web application.

Thanks
Coman
Saturday, July 29, 2006
 
 
1)  Not nearly enough information to answer this question.  Are your processing requirements high, or are you serving up basically static web pages?  How long is your average user session forecasted to be?  Will this application see high concurrency or are accesses going to be random across 24 hours?

Example: 1000 users scattered over the course of a day accessing mostly static web pages can be served on any free web host that exists.  1,000 peak concurrent users interacting with an AJAX app which makes multiple expensive database calls every second will bring a $10 a month web account to its knees.

2)  Your web host will probably (probably!) have backups.  Accessing them will probably require putting in a support ticket with a 24-48 hour turnaround.  Do you want to be in a position where customers are wondering why their business is at a standstill and you can only say "I emailed the guy, give me a day or two"?

3)  Depends on the provider.  Paypal will let you do it, eSellerate not so much.  Note you'll have problems if your recurring payment is not the same number every billing cycle.
Patrick McKenzie Send private email
Sunday, July 30, 2006
 
 
"Is the above configuration sufficient for running a web-app to handle say 1000 users."

Most likely. 

"When should I think of moving to a more "reliable" (if required) service?"

When you need it; you'll start to know immediately when you application needs more horsepower.  It's likely to sneak up on you gradually.  A PHP/MySQL site is extremely easy to move.  One of my sites, www.coffeegeek.com, started on a small shared server, moved to a more powerful shared server, moved to a dedicated server with other sites of ours, then moved to it's own server, then moved to a more powerful server, then was split between two servers, and is about to be moved again.  This was over the course of 6 years.

"The app will be handling user data related to their business. So I guess database backup is a MUST."

I have a similar sort of project currently in beta -- backups are very important.  Some hosting providers will do backups; if they do, that's a bonus.  I recommend looking into a box with RAID; I have, in the past, had a harddrive failure but the host was able to get us backup without any loss (although it did take 6 hours).

I have an automatic backup process setup myself that takes a periodic snapshot of the database and downloads it to one of my computers.  I also have a daily process that backs up the MySQL transfer log.  So I can always restore the site to the previous day.  Don't trust the host to do backups and do it right.

"Do I daily download the database folder to my local machine and back it up? Please clarify this point."

If using MySQL, there are two options.  One is the mysqldump command -- that will give you a text dump of the database.  The other is the binary transaction log -- the log contains all the modication queries executed on your database.  You can use these both together to do incremental backups.  In most cases, you will not have access to the database folder in a shared hosting environment (or the transaction log).  You might only have access to mysqldump.  That should, however, be fine while you are still small.

"How can I handle subscription payment? I don't want to setup a merchant account for now."

I *highly* recommend getting your payment stuff in order when you're small.  Don't dick around with this.  Get a proper merchant account and payment processor.

"Anything else you think that I may not know about running a free+paid web application."

If you're hold important business information you might want some redundancy.  It might be worthwhile to get a second hosting account on a different server and store a copy of the site there.  If you have a serious failure you can restore your backup and direct people there.
Almost H. Anonymous Send private email
Sunday, July 30, 2006
 
 
I think you're looking at this the wrong way. If your potential customers were to read this post, would they feel confident using your service?

Do some research, figure out what you need for infrastructure, then build your app.

Take time to do it the right way.
*myName
Sunday, July 30, 2006
 
 
Regarding your backup strategy, here's what I'd recommend:

Google for "MySQL Replication". You'll want to set up your primary MySQL database server as a "Replication Master". Then you can set up a "Replication Slave" at a remote location. All data from the master will be automatically backed up to the slave location on a continuous basis.

At first, you can just use your development box (or some other PC) as the replication slave, and then you can burn copies of the database to CDs periodically.

When you get a little more sophisticated, you can host your replication slave in the same data center as the master, and you can setup automatic failover (if the master goes down, then the application automatically uses the slave instead).
BenjiSmith Send private email
Tuesday, August 01, 2006
 
 
*myName-

I had the same initiate reaction, then I actually thought about my response.

Coman's posting DOES fall under the heading of "research."  Cut him some slack.  Sheesh.
Caffeinated Send private email
Thursday, August 03, 2006
 
 
Caffeinated,
 I think my questions here are part of my research. Why it is not?

Anyways, thanks for your comments.
Coman
Friday, August 04, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz