How to implement exchange rate in PHP?

Question

How does major sites implement this?

Do they hardcode the rate or look it up each time?

Answer 1

An idea would be :

• to call some external API regularly, to always have some fresh exchange rate (I don't know how often this can change -- but looking the rate up once every couple of minutes should do)
  • This could be done via some sort of cron job, independantly of your web-application that uses this exchange rate
• and to keep the exchange rate in cache for a couple of minutes :
  • so you don't call the external API too often
  • and don't rely on it too much (i.e. your site will still work if the site you're fetching the rate from is down for a couple of minutes -- and if it takes time to fetch that data, it won't slow your website down, as it's fetched regularly by a cron job)

Answer 2

I would imagine they define an acceptable margin of time in which they will consider the rate "solid" and only do lookups when that expires (whether that's 30 minutes or 6 hours would depend on your decision). How you accomplish this goal could be one of several things, the two best of which I would think are:

Store the rate, and time of lookup, in MySQL

Fairly simple, store the rate of X-to-Y in a MySQL lookup table. You will want to use the Memory (HEAP) Storage Engine because this will need to be fast and account (potentially) for DELETE operations once a record has expired (you may consider storing the values in a permanent table for historical purposes).

You'll need to implement a garbage collection routine to clear out the old entries once they are properly dead, and I would recommend using a stored procedure for this, while using a PHP script to give the SP a 1-in-10 chance of running.

EDIT: Of course you could use something other than MySQL, but I tend to recommend it if only because it's part of the common PHP development stack, and it's fairly easy to assume you'll have it. And, hey, if you don't, hopefully there is some equivalent in your RDBMS of choise.

Store the rate in a memory cacheing system (e.g. memcached)

This is significantly easier as it doesn't require you to design a database schema, garbage collection routine, etc, but it also doesn't give you the flexibility to include historical data as part of your garbage collection process, so if you intended to keep it, you'd need to store it as history as soon as you got it.

Which is better?

Honestly, it's personal preference. In either case, it's volatile data, so storing it in memory is definitely the way to go. If you're more comfortable with MySQL than Memcached, or vice-versa, then go with what you know.

Cron-based loading or Lazy-loading?

Depends on how busy you expect this to be; if only a few people will use it per day (internal app for an accounting department, for example) then I would definitely vote for "Lazy Loading" since you could then limit your requests to just what you need.

Alternatively, if you expect thousands (or even hundreds) of users daily, then a cron-based system may be ideal as the occasional user won't have to wait for the data to be fetched when it's not fresh. Using a cron-based system, however, should not be a substitute for having a proper Garbage Collection system (in case you are using a solution which doesn't come with one built in, like memcached), and in case of job failure, the application should still be capable of lazy-loading on demand if the data is too stale or not present.

Answer 3

As the other answers point out, you will need access to an API of some sort. With exchange rates, though, the much bigger problem is going to be finding one that doesn't cost an arm and a leg. I know only one, XE.com. They have a real web service starting at $540/year, ad-less calculator embeds for the web site and an ad-driven free embed or popup.

Answer 4

The various Central Banks, for example the ECB, provide Forex rates free to the public.

There is a PEAR package for Forex Rates and it is also not hard to code it yourself. Since the data is usually updated on a daily basis, you will want to add caching, so as not to hammer the bank's server.

However, if your application is doing any time-critical conversion, you should resort to a commercial service, as these usually update more frequently. I think Yahoo and Google have a financial API and someone already mentioned XE.com.