Abstract: Described are techniques for determining relationships between related processes and, based on the relationships, determining a critical path for at least a subset of the processes. The critical path for a process may be identified by determining whether a process is able to execute after each input received by the process. When the process is able to execute, the preceding process that provided the latest-received input may be identified. The process may be repeated for one or more preceding processes until a root process is determined. Based on the critical path data for a process, changes in latency due to a change in the critical path, a change in latency for an existing process, or the addition of a new process may be determined.

Abstract: Techniques are described for determining test cases to test a service, such as a service to manage a purchase contract in an e-commerce environment. Log data may be generated during execution of the service to process requests, the log data indicating a plurality of code segments that executed during the execution of the service. The log data may be analyzed to generate metrics data comprising a plurality of records corresponding to the processed requests. A record may include any number of counters that each indicates whether, or how many times, a particular code segment executed during processing of a request. The metrics data may be analyzed to identify a subset of records comprising representative combinations of the counters in the metrics data. The requests corresponding to one or more of the subset of records may be replayed to test the service.

Abstract: Techniques are described for asynchronous communication of transaction data to client processes. A transaction request may be sent from a client process to a contract engine, which may perform multiple service calls to network services to generate transaction data for the transaction. The transaction data may be stored in an aggregate contract data object, and provided asynchronously to the client process for presentation via a user interface such as an e-commerce application. In some cases, the client process may, subsequently to the initial transaction request, send one or more requests for portions of the transaction data. Such requests may be sent asynchronously with respect to the initial transaction request. In some cases, the client process may provide callback information specifying a network location to which transaction data may be asynchronously communicated after it has been generated.

Abstract: Techniques are described for parallel processing of items, specified for purchase in a transaction. A transaction request may be received, specifying a plurality of items in a transaction. Multiple subsets of one or more items may be determined that are suitable for parallel processing by multiple instances of a network services, the subsets determined based on configuration information describing a parallel processing capability of the network service specified during registration. Multiple service calls may be made to cause the multiple instances of the network service to generate transaction data corresponding to the subsets. The transaction data may be incorporated into an aggregate contract data object on receipt, and provided to client process(es) for presentation via a user interface such as an e-commerce application.

Abstract: A data aggregation service is configured to minimize the number of service calls made to network services. The data aggregation service might be configured to cache objects returned in response to service calls to network services in a shared data object. A hash of the input values in the service calls to the network services may be utilized to determine whether an object referenced by the cache can be utilized instead of making another service call. The data aggregation service might also be configured to utilize change tracking to determine when calls are to be made to dependent services. The data aggregation service might also be configured to utilize data-specific time to live (“TTL”) values, to allow network services to specify the data they are interested in at a granular level, and/or to perform automated optimization of TTL values. Other optimizations might also be implemented by the data aggregation service.