My friend Kenny has decided to also talk about performance. Given the magnitude of the traffic on eBay and the number of rules they need to activate, I can’t think of a best person to talk about scalability issues. Disclaimer, Kenny will be my co-presenter next week at Business Rules Forum 😉
My friend Kenny has decided to also talk about performance. Given the magnitude of the traffic on eBay and the number of rules they need to activate, I can’t think of a best person to talk about scalability issues. Disclaimer, Kenny will be my co-presenter next week at Business Rules Forum 😉
The fraud detection architecture applies rules and models as a service, invoked either synchronously (SOAP interface to the application) or asynchronously (via a message bus). The presentation focuses on making faster and more scalable real-time decisions.
From a developer / architect perspective, it would be more comfortable to preocess the cases offline of course but the nature of the business requires more timely detection – both in terms of revenue protection and customer satisfaction.
Fraud detection is the result of expert rules and data-driven analytics. Neural nets can detect trends that are buried in past transactions. Rules address flash fraud detection, e.g. patterns identified by fraud experts before models have had a chance to learn about those. As expected both of them require a ton of data to make good decisions, including some sophisticated computations. Data retrieval and normalization takes most of the transaction time. In the end, neural net processing represents only 2% of the time, and rules 3%.
Logically, many performance efforts by Kenny’s team have been focused on data. Data access is one area that Kenny covered. More interestingly, he analyzed other related avenues that relate more directly to decisioning “optimizations”:
- Unnecessary variables
- Excessive logic
- Conflicting logic
Independently, optimization techniques:
- Pre-fetch — although it goes against the very flexible and dynamic nature of rules
- Lazy load: only when needed, with smart ordering of conditions from most discriminating / cheaper to least — not always easy to estimate though
- Pre-aggregation of data — freshness can be addressed by aggregating up to “yesterday” for example and then look at real-time data for the current day only
Distributed locality could be addressed with distributed hash tables and other architecture tactics that Kenny quickly went through.
Horizontal scability with server clusters, etc. Database partition can help, based on data access patterns — per seller, per IP address.
Scalability for Rule Authoring
Sharing variables implies srong capabilities to catalog and describe variables so that all modelers and rules writers can safely and conveniently reuse those characteristics.
Great plug for Sparkling Logic — Thanks! But seriously, Kenny really appreciated the fluid metaphors we came up with, which help address that very set of problems.
Scalability for Rule Deployment
The continuous integration of rules allows to detect problems earlier and more frequently. As an added bonus the deployment is ready when it is time to deploy.
Statistical testing is similar to Champion Challenger in the sense that it allows the experts to compare the Production rules with the new Testing rules. Kenny went a little fast
Other techniques like smoketests and incremental deployment allow to test without impacting the entire workload.
Dog-food approach: Kenny also uses rules to monitor rules. Smart.
As you can imagine, constant monitoring allows to ensure that they are on-target with their performance objectives.
Closing remark: Fraudsters are very creative so catching them is like a game of Catcha Mouse!
Wow… What a fast speaker!
Check out the abstract here.
Powered By WizardRSS.com | Full Text RSS Feed | Amazon Plugin | Settlement Statement