Testimonials

Developing custom backend solutions to problems has two major flaws:

It takes a long time to implement (the three logic packages.)

It takes a dedicated staff to maintain.

Best solution

Buy a full feature backend process manager into which any application may easily fit.

Credit card processor

Fraud detection in credit cards is evolutionary. As soon as the fraud door is closed the thieves find a new door. There are hundreds of individual criteria in several major categories that may have to be checked and the legitimate customer cannot be kept waiting while the program checks one criterion at a time.

Problem

The volume of requests was staggering. Checking for lengthening path fraud criterion in a linear fashion for each request meant that the only way to increase the number of requests per hour was to increase the amount of hardware. This solution lead to diminishing returns.

Solution

Do the request as a backend process with multiple queues for each request depending on the category.

By placing the request into multiple queues, accesses may proceed in parallel cutting down on response time. The logic may process many requests within each queue during each access thereby reducing overhead. Additionally, each queue is isolated from the other queue and is not affected by errors on other queues.

Timeframe

The business logic was already written.

The infrastructure logic of developing a backend queuing and tasking structure took over seven man months. Three logic packages were needed to manage this totally asynchronous environment: 1 – the error recovery logic. 2 – the dynamic alterations to an ever-changing environment logic. 3 – the monitoring logic so system administrators could gauge the impact on the servers.

Maintenance

The processing company needed to train a dedicated staff in how to maintain a backend queuing and tasking structure. (Something business programmers usually never do.)

Clearing house

Every trade has two transactions -- a sell and a buy. As the trading volume increases, the verification process increases two fold.

Problem

The sell and buy transactions didn't always come in together and they sometimes didn't match. This meant that every sell had to go looking for it's buy and vice versa. As trade volume increased, the network was brought to its knees.

Solution

Pump each transaction into a sorted, prioritized backend queue. Let agents (tasks) work the queues thus keeping the network traffic to a minimum.

By placing the transaction into a backend queue, accesses may proceed between queues instead of across a network cutting down on response time and reducing overhead. Additionally, each queue is isolated from the other queue and is not affected by errors on other queues.

Timeframe

The business logic of matching was already written. The rewrite of looking within a queue rather than on the network was fairly simple.

The infrastructure logic of developing a backend queuing and tasking structure took over three man months. Again, three logic packages were needed to manage this totally asynchronous environment.

Maintenance

The clearing company needed to train a dedicated staff in how to maintain a backend queuing and tasking structure. (Something business programmers usually never do.)

Bank

Traditionally, back room processing at large banks was done in batches at night. The batches were sorted and organized for efficiency. Payments to other banks and the Fed was also held until the morning. Moving to a real-time system was mandated.

Problem

Every process was a batch process. Moving into real-time meant that every program in every system had to be completely rewritten. A seemingly impossible task.

Solution

Backend queue processing is essentially batch processing.

Place each order into a sorted backend queue. Using trigger levels, let tasks work the queues thus keeping the bulk of the current programs with little modification. When the processing completes, place the payment into a transmission queues for the Fed and other banks.

Timeframe

The business logic was already written. The restructuring took a fraction of what it would have taken to completely rewrite the logic.

The infrastructure logic of developing a backend queuing and tasking structure took over five man months. Again, three logic packages were needed to manage this totally asynchronous environment.

Maintenance

The bank needed to train a dedicated staff in how to maintain a backend queuing and tasking structure. (Something business programmers usually never do.)

Shipping company

Customer’s shipping information needed to be stored in a huge relational database and made available for inquiry and update.

Problem

There were tens of thousands of customers adding shipping information simultaneously with a limited number of connections to the computing facility. Additionally, placing the shipping information in a very large relational database was slow. The company needed to capture the information very quickly and release the connection for the next customer.

There were hundreds of thousands of customers and delivery personnel making inquiries and updates, again, with a limited number of concurrent connections.

Solution

Do the shipping request as a two-part transaction. Save the shipping information in a very fast local file giving the customer a receipt for it and do the database work in a backend process. This is the traditional backend scenario: dump it into a backend queue and let another process handle the work.

Secondly, handling large numbers of database inquires and updates with a limited number of connections severely limited the throughput. The solution again was backend processing. They dedicated some connections for input and some for output. They placed all the requests into queues for backend processing. When the process completed, the reply went into output queues for subsequent transmission to the customer.

Timeframe

The business logic was fairly simple.

The infrastructure logic of developing a backend queuing and tasking structure for the first scenario took over three man months and for the second scenario over six man months. Again, three logic packages were needed to manage this totally asynchronous environment.

Maintenance

The shipping company needed to train a dedicated staff in how to maintain a backend queuing and tasking structure. (Something business programmers usually never do.)

Security firm

Customers who trade during the day traditionally get a portfolio revaluation at the end of each business day. The revaluation reflects the current value of each financial instrument at the close of day.

Some customers who make large trades during the day want an instant picture of where they stand; that is – a portfolio revaluation during the day.

Problem

A portfolio revaluation is an intensive operation. It requires connections to all the exchanges and a great deal of computing. Doing the revaluation while the customer waits for the result ties up the customer’s access to do any other work. The connection is essentially locked for the duration.

Solution

Do the request as a backend process with a callback to the customer when the request completes (autonomous processing).

By placing a request in a queue for each exchange, the logic may process many requests within each queue during each access to the exchange thereby reducing overhead. Additionally, each queue is isolated from the other queues and is not affected by errors on those other queues.

This frees the customer’s connection to the firm so the customer can do other work.

Timeframe

The business logic to access the exchanges and compute the results was already written. With little modification this logic was converted from a nightly function to a real-time function. The callback logic to the customer was relatively simple. This was essentially today’s equivalent of an “instant message”.

The infrastructure logic of developing a backend queuing and tasking structure took over eight man months. Each exchange connection was a separate queue with its own tasks. Again, three logic packages were needed to manage this totally asynchronous environment.

Maintenance

The firm needed to train a dedicated staff in how to maintain a backend queuing and tasking structure. (Something business programmers usually never do.)

The three logic packages.

Just what is error recovery? Some elements are:

Intermediate back-out of requests.
When placing a request into multiple queues, if one of those queues is full or has an error, then the request should be purged from all previously accessed queues.

Request timeout.
Even for autonomous requests, no request may linger in a queue indefinitely. In backend processing, all resources are only “leased”. The cause of the delay must be identified and corrected. Additional recovery is similar to the intermediate back-out.

Application failure.
Even the best written programs fail. System administrators must be notified immediately. The queue must be shut down until the problem is fixed. Additional recovery is similar to the intermediate back-out.

What is dynamic alteration of the environment? Some elements are:

Changing the number of elements within each queue.
Changing the threshold limits watching each queue for creating a new task.
Changing the time each task waits for new work before destroying the task.
Changing the status of executing tasks.
Re-scheduling stalled requests.

What is the monitoring logic? Some elements are:

The ability to save the end-of-day statistics.
The ability to get a snap shot of the total environment during execution, (current statistics)
The ability to log and message administrators
The ability to see “what tasks are doing what.”
The ability to see how many request are executing and pending
The ability to see any stalled requests.
The ability to trace autonomous requests.