SDK instrumentation

In many cases, SDK instrumentation can and should be done in the code itself rather than further down the stack. Because all products tie into one service in a multi-system or service-oriented architecture, you can instrument in one place. This simplifies the initial deployment as well as updates and maintenance.

This approach can work if you need results in real time, but if you need real-time results, consider encapsulating information in an API instead.

For example, consider an event ticketing application. The application includes a module called buy_tickets that's driven by Java on the backend. In a queue-based model, all information about a user interaction is captured in a slot in the queue. The application will process the sign-in in real time, but it will not necessarily do the same for all the actions related to that sign-in. Event processing speed in the queue depends on the volume of events and the backend's ability to handle the traffic. As a result, there may be some lag in delivering A/B test results.

Now imagine 1 million people use this application at the same time. If the app tries to record the success or failure of an A/B test somewhere on the site, those results will likely not be delivered in real time under a queue model. If, however, these events are tracked through an Optimizely API, the results would be available immediately, with no noticeable lag.

If real-time results are important to you, instrument your events at the place where they actually happen.