Scribd
Upload
5K views3 pages

Choose SLI Specifications and Refine Them Into SLI Implementations For Another, More Complex User Journey.

The document discusses setting up Service Level Indicators (SLIs) and specifications for measuring the performance of a user purchase journey in a game. It proposes measuring the availability and latency of retrieving a list of SKU IDs from the server. For latency, the SLI would measure the percentage of successful SKU requests completed within 10 seconds. It also discusses measuring the latency and response codes for completing a purchase on the server after a transaction with the external payment provider.

Uploaded by

محمد يوسف
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
5K views3 pages

Choose SLI Specifications and Refine Them Into SLI Implementations For Another, More Complex User Journey.

The document discusses setting up Service Level Indicators (SLIs) and specifications for measuring the performance of a user purchase journey in a game. It proposes measuring the availability and latency of retrieving a list of SKU IDs from the server. For latency, the SLI would measure the percentage of successful SKU requests completed within 10 seconds. It also discusses measuring the latency and response codes for completing a purchase on the server after a transaction with the external payment provider.

Uploaded by

محمد يوسف
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Choose SLI specifications and refine them into SLI implementations for another,

more complex user journey.


Develop SLI implementations that cover this user journey to your satisfaction.
Justify:

Your definitions of "good events" and "valid events" in your implementations.


The measurement methods used, and the trade-offs they involve.
Any parts of the journey you have chosen to leave uncovered.
The user click on a list of product. This will call an API that will get the list
of SKU.Here we can measure the GETSKU. There will a SKU detail request that will
lead to response from the play store.From there the user will choose the product
through the product ID and get the availability and the price.The SLI here will be
availability of GETSKU.
How can we do that :
We can measured the number of succesfull request GETSKU that return a list. There
we can have a min limit of response to 300 responses code.
This will trigger the billing flow.
We can also measured latency. This will be done through the time limit of response
to a query.That is a GETSKU will have a response that is a list of product.This
list should be available is a limited time that should not exceed 10 second.After
10 second , a cancel script should act and cancel the request an the user will send
a new request.
A positive SLI will be measured according the number of successfull request over
the number of user' queries.The percentage will now show us if we have a good time
of latency or not.
So our SLI here that we measured are availability and latency.
Availability will be measured fron the number of responses not lower than 300
response codes after a GETSKU. Latency will be measured through the number of
successfull request(in 10 sec) over the total number of user querries GETSKU.

The user happiness level depends on:


Accuracy of products displayed from list of SKU (availability of in-game purchases,
response if something is already owned)
Latency of /api/completePurchase to complete purchase, verify token, and update the
account
Correctness of product purchased

Definition of success - Successful status code for account update

We will set SLI specifications for freshness, correctness, coverage, and throughput
of the process to update the account after the purchase as well as the response
after the billing flow is complete.

Valid Events:

Get list of SKUs on server, return list to client SKU Details to Play Store and
return details to client Billilng flow to Play Store - status code, order ID,
purchase token to client API to complete purchase to server Server Verify Purchase
Token to Play Store > Status Code back to Server Update Account on the Server >
Status Code to Client

Good Events:

Successful display of available SKU IDs in client �buy stuff� UI


After sending /api/SKUs, it returns the SKU of the new released area for purchase
�Int OK� billing response code from the playstore after launching billing flow
Google Play responds when you successfully purchased an item. The response includes
a JSON string
Latency of /api/completePurchase to server
Status Code request verified successfully to the web server
Account successfully updated in the server with status code to client

The measurement methods used, and the trade-offs they involve.

Freshness - The proportion of valid data (successful status code after updating
account on server) updated x amount of seconds after request to
/api/completePurchase sent from client to server.

Correctness - Proportion of valid data (Parse JSON data from Play Store) producing
correct output. Measure correct output by using �golden input data� with known good
outputs. Compare data output to measure if it is correct/successful.

Coverage - Proportion of valid data processed successfully. Measure latency of


client to server api/completePurchase requests which results in a successful status
code after updating the account.

Throughput - proportion of time where the data processing rate is faster than a
threshold.
SLI for new area release - 10 purchases per second does not exceed x bytes per
second
SLI normally - 1 purchases per second does not exceed y bytes per second

Any parts of the journey you have chosen to leave uncovered.

SKU details request and response to the Play Store and back to client. Since the
Play Store is external and the SKU details response bypasses the server and goes
directly to the client.

A good event was an event that met SLI requirements/ A valid event was one that was
served successfully.
I chose to measure the response codes at the sever since the play store will send a
response code the the sever update the account the send a response code to the
client.

SLI: The proportion of sku id's or order id request that have a response code
0x00000000 measured at the server.

I chose the sever because during the purchase process it utilizes the
onPurchaseUpdate() which handles the response codes also at the end of user's
successful purchase the server generates a purchase token to validate success.

SLI Type: Latency

SLI Specification: Proportion of page requests that were served in < 200ms(Above,
�[page requests] served in <200ms� is the numerator in the SLIEquation, and �page
requests� is the denominator.)

SLI Implementations:
Proportion of page requests served in < 200ms, as measured from the 'latency'
column of the server log.
(Pros/Cons: This measurement will miss requests that fail to reach the backend.)

Proportion of home page requests served in < 200ms, as measured by probes that
execute JavaScript in a browser running in a virtual machine.
(Pros/Cons: This will catch errors when requests cannot reach our network, butmay
miss issues affecting only a subset of users.)

SLO:99% of home page requests in the past 28 days served in < 200ms.

You might also like