A callout lets salesforce.com access external data. This reduces the need to have an integration server acting as a synchronizing bridge between salesforce.com and that external data. You can use this to get the weather in Timbuktu, the current stock market value for a ticker symbol, credit ratings, process merchant account payments. Anything you can think of, there is probably a service that can do that.

Future methods run asynchronously. This means that the currently executing code continues without pause, and the future method is delayed until some point in the future by being placed into a queue. The asynchronous code will be that which is contained in the future method.

Consider synchronous vs asynchronous:

@future
public static void futuredebug(object x) {
  system.debug(x);
}

public static void currentdebug(object x) {
  system.debug(x);
}

// synchronous example:
@istest
public static void testsync() {
  test.starttest();
  currentdebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 1, 2
}

@isTest
public static void testasync() {
  test.starttest();
  futuredebug(1);
  currentdebug(2);
  test.stoptest();
  // OUTPUT is 2, 1
}

In this case, futuredebug is delayed until the end of the current transaction (simulated by test.stoptest()). In a non-test environment, futuredebug() would generate a separate debug log that started some point after the transaction that called it completed.

Waiting until resources are available means just that: the calls are placed into a queue, and processed in FIFO order. Normally this queue is short, but if many calls are made in a short time, they could build up and won't be processed immediately. If the queue is empty and the call is short, it is called immediately as the current transaction ends and is basically "tacked on" to the end of the transaction. The effect is that the user will see the new data immediately. Otherwise, the user will have to visit the record later to see the results of any future method.

In the example above, the code contained in futuredebug() was called at a later point in time, asynchronously from the main code.

Salesforce.com requires that no row-level locks are present on any records involved in a transaction before performing a callout. This is important for several reasons: UI responsiveness, integration responsiveness, and multi-tenancy friendliness.

The first requirement is borne out of the need for users to have fast, responsive UIs. If a callout called a synchronous web service, pressing the save button could result in a "white screen" for up to two minutes, causing the users to complain about how slow the app is.

The second requirement is the need to have integrations perform as quickly as possible. Long web service calls would lock out integrations randomly for no apparent reason, so they would have to retry their actions, causing wasted bandwidth, processing time, and necessarily making coding integrations more complex.

Finally, multi-tenancy refers to the ability to have many uses on a single application at once. In order to have this work well, all users have to be able to modify records in rapid succession. This would be impossible if records were locked all of the time because of long row-level locks. Locks are typically held only for a few seconds at most, allowing more users to use the system at once.

So, if you want to update a record in a multi-tenancy friendly method, you have to minimize row-level locking, maximize UI responsiveness, and play well with integrations that also need to read and write to the service.