Best Practices
Ensure that you have received acknowledgement after sending your usage data. If you receive 429 "Too Many Requests" or 5XX response, you need to resend your usage.
Metering data related to billing is quite important. Therefore it's required to ensure that it is processed by Abacus. To do so, you need to receive acknowledgement from Abacus that the data is received and processed.
A best practice is to be prepared for the case when your data is either rejected, due to service overload, or did not reached Abacus due to network instabilities.
You can implement:
- a mechanism that checks whether the metering data has been received by Abacus
- a storage/buffer for metering data that has not been received
- exponential retry logic for resending the data
For information on some of the possible ways to handle network instabilities, refer to Deal with Network Issues.
Due to limitation in current Abacus implementation, it's best to update plans as rarely as possible. Most convenient time to do this is in the beginning of the month. The reason behind this is that the new plan will be effective immediately and you might have inconsistent monthly report.
If you want to provide time-based metrics, you need to consider a "renewer component", that should take care of resubmitting cross-month usage data. This is required as Abacus uses different databases for each month.
If you use time-based metrics, you will only be able to see the usage in the daily window that corresponds to the end property of your usage. It will be present in the monthly usage report aggregation but will not be propagated in ongoing daily windows.
If this was not the case, posting start for time-based metric would mean you’ll be able to see it in each daily window in the future until you post stop event.
Abacus can return:
- 409 Conflict, when:
- Resource Provider (RP) sends data twice or the data is overlapping for a certain time period
- Abacus retried the usage internally due to network failures, app crashes, overload (429) or other reasons
- 429 Too Many Requests:
- when we cannot handle more requests in some of our processing stages
- Not bound to a specific RP, but global for all RPs (no quota yet)
The strategies to handle these responses:
- 409: ignore if usage is guaranteed to be unique; correct the usage and resend it otherwise
- 429: retry (preferably with exponential back-off)
| << Deal With Network Issues | Home>> |
|---|
