Need some inputs on my upcoming invoice system, [Php][Mysql]

[Jawn]

Hello all ,
Im about to start coding on my invoice system, and im in need of some help/inputs.

First of all i will show you how my servers are built up.

Software
Webpage1, webpage2, webpage3 are three different servers with three different webpages which stores invoices localy on each server.
Each of the webpages sell some kind of service (premium member etc).

Then we have my invoice server which will collect all invoices from each server once per day and put them in a queue table. This means that all invoices end up in correct line (dates etc). If one of the webpages goes down the invoice server halts and will continue to connect to the crashed server to gather the missing invoices.

If it succeeds to gather all invoices from all webservers it will start generating invoice numbers to all invoices and email em to the ones who payed.


Questions and problematics
What should i use to gather all invoice data? best coding way

I could write my own API but that's something really new to me maybe point me somewhere?

I could go for direct sql connections between the servers, what security risks are there?

Im planing to buy a Pentium 4 2.4Ghz 1GBRam 750Gb bandwidth, this is just for the invoice system.
Nothing else should be on it and its not more than 120 invoices per month. I have never used a P4 before is it stable? Ive always ran Dual Xeon or WoodCrest but i dont feel like paying that much for such a small system.


I would greatly appreciate ideas and inputs , i hope my post makes sence.


Best Regards
Jawn

 

[guillermobt]

Hello Jawn.

The key of your system: "not more than 120 invoices per month".
This is no work at all for such a proposed architecture.
Thousands of servers (database and/or web servers) are running everywhere on P4 (or even on PIII) without problems.

It's also true that if you keep an open eye and your main server includes a backup and fault tolerant subsystem, you will sleep much better.

Since the seliarization of invoices is given "naturally" by their arrival timestamp, I don't think you have problems to generate the correspondant unique code for each of them. Anyway, I would include a unique machine ID to avoid collisions in the (rare) case that more than one invoice arrive to the "Invoice server" at the very same time(stamp).

If you want stronger security, don't make your webservers (webpages) visible among them and put a firewall between the "Invoice server" and your pool of webservers.

Try to code "monolithic" SQL transactions (maybe through stored procedures) which will avoid potential data inconsistencies which may occur when there are several parallel sources of data feeding a given database.

Don't know if I just said obvious things or something of the above can help you some way.


Regards.

 

[Peter]

The server you propose is plenty for what you want.

Regarding coding an API I do not know of any sites that talk you though it but it is a fairly easy task to do. Before you go any further you should list the sort of things the external servers might need to do. Then methodically go through them and see what each entails. Also ensure that there is a way that each server can connect that is unique to that server as it will help in case of breaches.

I would advise against directly inputting the SQL as when you update the invoice server then you will have to update all other servers, on the other hand if you use an api you simply update the invoice server. The only time the other servers will have to be updated is when you change the api but if you plan it correctly and update correctly you can minimize this.