15 ਜੁਲਾ 2025·2 ਮਿੰਟ
ਉਪਯੋਗ-ਆਧਾਰਿਤ ਕੀਮਤ ਲਾਗੂ ਕਰਨਾ: ਮੀਟਰਿੰਗ ਅਤੇ ਰਿਕਨਸੀਲੇਸ਼ਨ
ਉਪਯੋਗ-ਆਧਾਰਿਤ ਬਿਲਿੰਗ ਲਾਗੂ ਕਰਨਾ: ਕਿਹੜੀ ਚੀਜ਼ ਮਾਪਨੀ ਹੈ, ਕਿੱਥੇ ਟੋਟਲ ਗਣਨਾ ਕਰਨੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਰਿਕਨਸੀਲੇਸ਼ਨ ਚੈਕ ਬਿੱਲਿੰਗ ਬੱਗਸ ਨੂੰ ਇਨਵਾਇਸ ਜਾਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੜਦੇ ਹਨ।
ਉਪਯੋਗ-ਆਧਾਰਿਤ ਬਿਲਿੰਗ ਲਾਗੂ ਕਰਨਾ: ਕਿਹੜੀ ਚੀਜ਼ ਮਾਪਨੀ ਹੈ, ਕਿੱਥੇ ਟੋਟਲ ਗਣਨਾ ਕਰਨੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਰਿਕਨਸੀਲੇਸ਼ਨ ਚੈਕ ਬਿੱਲਿੰਗ ਬੱਗਸ ਨੂੰ ਇਨਵਾਇਸ ਜਾਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੜਦੇ ਹਨ।
ਉਪਯੋਗ ਬਿਲਿੰਗ ਤਾਂ ਟੁੱਟਦੀ ਹੈ ਜਦੋਂ ਇਨਵਾਇਸ 'ਤੇ ਜੋ ਨੰਬਰ ਹੈ ਉਹ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਦਿੱਤੇ ਗਏ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਇਹ ਫਰਕ ਪਹਿਲਾਂ ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ (ਕੁਝ ਗੁਮ API ਕਾਲਾਂ), ਪਰ ਫਿਰ ਰਿਫੰਡ, ਗੁੱਸੇ ਵਾਲੇ ਟਿਕਟਾਂ, ਅਤੇ ਫਾਇਨੈਂਸ ਟੀਮ ਜੋ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੀ, ਬਣ ਸਕਦਾ ਹੈ।
ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦੇ ਹਨ। ਇਵੈਂਟਸ ਗੁੰਮ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਸਰਵਿਸ ਰਿਪੋਰਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਠੱਠ ਰਹਿ ਗਈ, ਕਿਊ ਡਾਊਨ ਸੀ, ਜਾਂ ਕਲਾਇੰਟ ਆਫਲਾਈਨ ਹੋ ਗਿਆ। ਇਵੈਂਟਸ ਦੋ ਵਾਰੀ ਗਿਣੇ ਜਾ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਹੋਏ, ਵਰਕਰ ਨੇ ਇੱਕੋ ਮੈਸੇਜ ਮੁੜ-ਪ੍ਰੋਸੈਸ ਕੀਤਾ, ਜਾਂ ਕੋਈ ਇੰਪੋਰਟ ਜੌਬ ਫਿਰ ਚੱਲ ਗਿਆ। ਸਮਾਂ ਆਪਣੀ ਸਮੱਸਿਆ ਲਿਆਉਂਦਾ ਹੈ: ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਘੜੀ ਦਾ ਡ੍ਰਿਫਟ, ਟਾਈਮ ਜ਼ੋਨ, ਡੇਲਾਈਟ ਸੇਵਿੰਗਜ਼, ਅਤੇ ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੇ ਇਵੈਂਟਸ ਵਰਤੋਂ ਨੂੰ ਗਲਤ ਬਿਲਿੰਗ ਪੀਰੀਅਡ ਵਿੱਚ ਧੱਕ ਸਕਦੇ ਹਨ।
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ: ਇੱਕ ਚੈਟ ਪ੍ਰੋਡਕਟ ਜੋ ਹਰ AI ਜਨਰੇਸ਼ਨ 'ਤੇ ਚਾਰਜ ਕਰਦਾ ਹੈ, ਇੱਕ ਇਵੈਂਟ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦੂਜਾ ਜਦੋਂ ਉਹ ਮੁਕੰਮਲ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਟਾਰਟ ਇਵੈਂਟ ਤੋਂ ਬਿਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ fail ਹੋਣ 'ਤੇ ਵੀ ਚਾਰਜ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਫਿਨਿਸ਼ ਇਵੈਂਟ ਤੋਂ ਬਿਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਓਹ ਵਰਤੋਂ ਗੁਆ ਸਕਦੇ ਹੋ ਜਦੋਂ ਅਖੀਰੀ ਕਾਲਬੈਕ ਆ ਹੀ ਨਾ ਪਵੇ। ਜੇ ਦੋਹਾਂ ਨੂੰ ਬਿਲ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਤੁਸੀਂ ਡਬਲ ਚਾਰਜ ਹੋ ਜਾਵੋਗੇ।
ਕਈ ਲੋਕਾਂ ਨੂੰ ਇੱਕੋ ਨੰਬਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:
ਲਕਸ਼ ਸਿਰਫ਼ ਸਹੀ ਟੋਟਲ ਨਹੀਂ। ਲਕਸ਼ ਸੁਝਾਊ ਇਨਵਾਇਸ ਅਤੇ ਤੇਜ਼ ਵਿਵਾਦ ਸਾਂਭਣ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ line item ਨੂੰ ਕੱਚੇ ਉਪਯੋਗ ਤੱਕ ਟਰੇਸ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇੱਕ ਆਉਟੇਜ ਤੁਹਾਡੀ ਬਿਲਿੰਗ ਨੂੰ ਅਨੁਮਾਨੇ ਬਣਾ ਦੇ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਵੇਲਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬਿਲਿੰਗ ਬੱਗਸ ਬਿਲਿੰਗ ਇੰਸੀਡੈਂਟ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਸ ਚੀਜ਼ ਲਈ ਚਾਰਜ ਕਰ ਰਹੇ ਹੋ? ਜੇ ਤੁਸੀਂ ਇਕਾਈ ਅਤੇ ਨਿਯਮ ਨੂੰ ਇਕ ਮਿੰਟ 'ਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਸਿਸਟਮ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲੱਗੇਗਾ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਇਹ ਪਤਾ ਲੱਗੇਗਾ।
ਹਰ ਮੀਟਰ ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਚਾਰਜ ਕਰਨ ਯੋਗ ਇਕਾਈ ਚੁਣੋ। ਆਮ ਚੋਣਾਂ ਹਨ: API calls, requests, tokens, compute ਮਿੰਟ, GB ਸਟੋਰੇਜ, GB ਟ੍ਰਾਂਸਫਰ, ਜਾਂ ਸੀਟਸ। ਮਿਲੀਜੁਲੀਆਂ ਇਕਾਈਆਂ (ਜਿਵੇਂ “ਐਕਟਿਵ ਯੂਜ਼ਰ ਮਿੰਟ”) ਤੋਂ ਬਚੋ ਜਦ ਤਕ ਤੁਹਾਨੂੰ ਵਾਕਈ ਲੋੜ ਨਾ ਹੋਵੇ—ਉਹ ਆਡੀਟ ਅਤੇ ਸਮਝਾਉਣ ਲਈ ਔਖੇ ਹੁੰਦੇ ਹਨ।
ਵਰਤੋਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਵਰਤੋਂ ਕਦੋਂ ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ: ਟ੍ਰਾਇਲ ਵਿੱਚ ਮੀਟਰਡ ਓਵਰੇਜ ਸ਼ਾਮਲ ਹਨ ਜਾਂ ਇੱਕ ਕੈਪ ਤੱਕ ਮੁਫ਼ਤ? ਜੇ ਤੁਸੀਂ ਗਰੇਸ ਪੀਰੀਅਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਸ ਦੌਰਾਨ ਦੀ ਵਰਤੋਂ ਬਾਅਦ ਵਿੱਚ ਬਿਲ ਕੀਤੀ ਜਾਏਗੀ ਜਾਂ ਮੁਆਫ ਕੀਤੀ ਜਾਏਗੀ? ਯੋਜਨਾ ਬਦਲਾਅ ਜਿੱਥੇ ਗਲਤ ਫਹਿਮੀਆਂ ਵੱਧਦੀਆਂ ਹਨ, ਉਥੇ ਪ੍ਰੋਰੇਟਿੰਗ, ਫੌਰੀ ਰੀਸੈਟ ਸਹਿਤ ਫੈਸਲੇ ਕਰੋ।
ਗੋਲਿੰਗ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਲਿਖੋ; ਉਹ ਇਮਪਲਾਈਡ ਛੱਡੋ ਨਾ। ਉਦਾਹਰਣ ਲਈ: ਸਭ ਤੋਂ ਨੇੜੇ ਸਕਿੰਡ/ਮਿੰਟ/1,000 tokens ਤੱਕ ਗੋਲ ਕਰੋ; ਰੋਜ਼ਾਨਾ ਘੱਟੋ-ਘੱਟ ਚਾਰਜ ਲਗਾਓ; ਜਾਂ 1 MB ਵਰਗਾ ਘੱਟੋ-ਘੱਟ ਚਾਰਜਇਯੋਗ ਇੰਕ੍ਰੀਮੈਂਟ ਲਗਾਓ। ਇਹ ਛੋਟੇ ਨਿਯਮ ਵੱਡੇ “ਮੈਨੂੰ ਕਿਉਂ ਚਾਰਜ ਕੀਤਾ?” ਟਿਕਟ ਬਣਾਉਂਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ ਨਿਯਮ ਜੋ ਪਹਿਲਾਂ ਫਿਕਸ ਕਰਨਯੋਗ ਹਨ:
ਉਦਾਹਰਣ: ਇੱਕ ਟੀਮ ਪ੍ਰੋ 'ਤੇ ਹੈ, ਫਿਰ ਮਧ-ਮਹੀਨੇ ਵਿੱਚ ਅੱਪਗ੍ਰੇਡ ਕਰ ਲੈਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਅੱਪਗਰੇਡ 'ਤੇ allowances ਨੂੰ ਰੀਸੈਟ ਕਰ ਦਿੰਦੇ ਹੋ, ਉਹ ਹਨ effectively ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਦੋ ਮੁਫ਼ਤ allowances। ਜੇ ਤੁਸੀਂ ਰੀਸੈਟ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਉਹ ਆਪਣੇ ਅੱਪਗਰੇਡ ਲਈ ਸਜ਼ਾਇਆ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹਨ। ਦੋਹਾਂ ਚੋਣਾਂ ਵੈਧ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਲਗਾਤਾਰ, ਦਸਤਾਵੇਜ਼ਿਤ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਉਪਯੋਗ ਬਿਲਿੰਗ ਉਸ ਸਮੇਂ ਟੁੱਟਦੀ ਹੈ ਜਦੋਂ ਇਨਵਾਇਸ ਦੇ ਅੰਕ ਉਹ ਨਹੀਂ ਹੁੰਦੇ ਜੋ ਪ੍ਰੋਡਕਟ ਨੇ ਅਸਲ ਵਿੱਚ ਦਿੱਤੇ।
ਆਮ ਕਾਰਨ ਹਨ:
ਇਸ ਦਾ ਫਿਕਸ “ਵਧੀਆ ਗਣਿਤ” ਤੋਂ ਘੱਟ ਅਤੇ ਇਵੈਂਟਸ ਨੂੰ ਠੀਕ, ਡੀਡਿਊਪ ਕੀਤਾ ਅਤੇ ਪੂਰੇ ਤੌਰ 'ਤੇ ਸਮਝਣ ਯੋਗ ਬਣਾਉਣ ਬਾਰੇ ਹੈ।
ਹਰ ਮੀਟਰ ਲਈ ਇੱਕ ਸਾਫ਼ ਇਕਾਈ ਚੁਣੋ ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਇਸ ਦੀ ਪਰਿਭਾਸ਼ਾ ਲਿਖ ਦਿਓ (ਉਦਾਹਰਣ: “ਇੱਕ ਸਫਲ API ਬੇਨਤੀ” ਜਾਂ “ਇੱਕ AI ਜਨਰੇਸ਼ਨ ਮੁਕੰਮਲ”)।
ਫਿਰ ਉਹ ਨਿਯਮ ਲਿਖੋ ਜਿਨ੍ਹਾਂ ਤੇ ਗਾਹਕ ਵਾਦ ਕਰੇਗਾ:
ਜੇ ਤੁਸੀਂ ਇਕਾਈ ਅਤੇ ਨਿਯਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਆਡੀਟ ਅਤੇ ਸਹਾਇਤਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।
ਸਿਰਫ਼ ਖਪਤ ਹੀ ਨਹੀਂ, ਉਹ ਇਵੈਂਟ ਵੀ ਟ੍ਰੈਕ ਕਰੋ ਜੋ ਪੈਸੇ ਨਾਲ ਸਬੰਧਤ ਤਬਦੀਲੀ ਕਰਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ:
ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਯੋਜਨਾਂ ਦੇ ਬਦਲਾਅ ਜਾਂ ਸਹੀ ਕਰਨ ਤੇ ਇਨਵਾਇਸ ਦੁਬਾਰਾ ਬਣਾਏ ਜਾਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸੁਧਾਰੇ ਜਾ ਸਕਦੇ ਹਨ।
ਉਤੈਜਨਾ ਦੇ ਸੰਦਰਭ ਨੂੰ ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ‘ਮੈਂ ਕਿਉਂ ਚਾਰਜ ਕੀਤਾ ਗਿਆ?’ ਦਾ ਜਵਾਬ ਬਿਨਾਂ ਅਟਕਾਉਂਦੇ ਦੇ ਸਕੋ:
occurred_at UTC ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਇੱਕ ਇੰਜੈਸਟ ਟਾਈਮਸਟੈਂਪਸਪੋਰਟ-ਗਰੇਡ ਮੈਟਾਡੇਟਾ (request/trace ID, ਰੀਜਨ, ਐਪ ਵਰਜ਼ਨ, ਪ੍ਰਾਇਸਿੰਗ-ਰੂਲ ਵਰਜ਼ਨ) ਵੀ ਵਾਦਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ suljhane ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਬਿਲਿੰਗ-ਯੋਗ ਇਵੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਸਿਸਟਮ ਜਿੱਥੇ ਕੰਮ ਹਕੀਕਤ ਵਿੱਚ ਹੋਇਆ, ਉਥੇੋਂ ਜਾਰੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ—ਅਕਸਰ ਤੁਹਾਡਾ ਬੈਕਐਂਡ, ਬਰਾਊਜ਼ਰ ਜਾਂ ਮੋਬਾਈਲ ਨਹੀਂ।
ਭਰੋਸੇਯੋਗ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਬਿੰਦੂ ਅਜਿਹੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਕੰਮ ਅਪਰਿਵਰਤਨੀ ਹੋ:
ਆਫਲਾਈਨ ਮੋਬਾਈਲ ਇੱਕ ਐਕਸੇਪਸ਼ਨ ਹੈ—ਉਥੇ ਲੋਕਲ ਟਰੈਕ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ; ਇਸ ਲਈ ਯੂਨੀਕ ਇਵੈਂਟ ID, ਡਿਵਾਈਸ ID ਅਤੇ ਮੋਨੋਟੋਨਿਕ ਸੀਕਵੈਂਸ ਨੰਬਰ ਵਰਗੇ ਗਾਰਡਰੇਲ ਲਗਾਓ ਅਤੇ ਸਰਵਰ ਵੈਰੀਫਾਈ ਕਰੇ।
ਤੁਹਾਨੂੰ ਦੋ ਚੀਜਾਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਦੁਹਰਾਈ ਹੋਣ ਵਾਲੀਆਂ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਬਾਅਦ ਵਿੱਚ ਬਚਾਉਂਦੀਆਂ ਹਨ: ਅਟੁੱਟ ਰਾ-ਈਵੈਂਟਸ (ਕੀ ਹੋਇਆ) ਅਤੇ ਡੈਰੀਵੇਡ ਟੋਟਲਸ (ਜੇਹੜੇ ਤੁਸੀਂ ਬਿਲ ਕਰੋਗੇ)। ਰਾ-ਈਵੈਂਟਸ ਤੁਹਾਡੀ ਸੋਰਸ ਆਫ਼ ਟਰੂਥ ਹਨ। ਏਗ੍ਰਿਗੇਟਸ ਉਹ ਹਨ ਜੋ ਤੇਜ਼ਲ ਨਾਲ ਪੁੱਛੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਨਵਾਇਸ ਬਣਾਉਂਦੇ ਹਨ।
ਟੋਟਲ ਕਿਸੇ ਵੀ ਇੱਕ ਥਾਂ 'ਤੇ ਕਮਪਿਊਟ ਕਰਨ ਦੇ ਦੋ ਆਮ ਢੰਗ ਹਨ: ਡੇਟਾਬੇਸ (SQL ਜੌਬ, ਮੈਟੀਰੀਅਲਾਈਜ਼ਡ ਟੇਬਲਾਂ) ਜਾਂ ਇੱਕ ਸਮਰਪਿਤ ਐਗਰੀਗੇਟਰ ਸੇਵਾ। ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਡੇਟਾਬੇਸ ਕਾਰਜ ਸਪੱਠ ਅਤੇ ਸੌਖਾ ਹੈ; ਇੱਕ ਛੋਟਾ ਅਗਰੀਗੇਟਰ ਵਰਕਰ ਵੈਰੀਜ਼ਨਿੰਗ ਅਤੇ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੈ।
ਕੀ ਤੁਹਾਨੂੰ ਦੋਹਾਂ ਲੇਅਰਾਂ ਰੱਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਪ੍ਰੈਗਟਿਕਲ ਸੈਟਅਪ:
ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਮੀਟਰਿੰਗ ਪਾਈਪਲਾਈਨ ਅਕਸਰ ਡਾਟਾ ਫਲੋ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕੜੇ ਗਾਰਡਰੇਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਢਾਂਚਾ ਸਹੀ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੀਮਤ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹੱਥੋਂ-ਹੱਥ ਸਾਰਾ ਕੁਝ ਮੁੜ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦੇ।
ਕਦਮ 1: ਮਾਮੂਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਵੈਂਟਸ ਨੂੰ ਸੰਜੋ
ਜਦੋਂ ਇੱਕ ਇਵੈਂਟ ਆਏ, ਤੁਰੰਤ ਵੈਲਿਡੇਟ ਅਤੇ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ। ਲੋੜੀਂਦੇ ਫੀਲਡ ਚੈੱਕ ਕਰੋ, ਇਕਾਈਆਂ ਬਦਲੋ (ਬਾਈਟ → GB, ਸਕਿੰਡ → ਮਿਨਟ), ਅਤੇ ਟਾਈਮਸਟੈਂਪਾਂ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਨੀਤੀ ਦੇ ਅਨুসਾਰ ਕਲੈਂਪ ਕਰੋ। ਗਲਤ ਹੋਣ 'ਤੇ, ਇਸਨੂੰ ਰੀਜੈਕਟ ਕੀਤਾ ਰਿਕਾਰਡ ਵਜੋਂ ਰੱਖੋ ਅਤੇ ਕਾਰਨ ਦਰਜ ਕਰੋ—ਚੁਪਚਾਪ ਡ੍ਰੌਪ ਨਾ ਕਰੋ।
ਆਪੈਂਡ-ਓਨਲੀ ਮਨਸੂਬਾ ਰੱਖੋ ਅਤੇ ਇਤਿਹਾਸ ਨੂੰ ਥਾਂ 'ਤੇ “ਫਿਕਸ” ਨਾ ਕਰੋ। ਰਾ-ਈਵੈਂਟਸ ਹੀ ਤੁਹਾਡੀ ਸਹੀ ਥਾਂ ਹਨ।
ਕਦਮ 2–6 ਪ੍ਰਭਾਵੀ ਤਰੀਕੇ ਨਾਲ:
ਡਬਲ ਚਾਰਜਿੰਗ ਅਤੇ ਗੁਮ ਹੋਈ ਵਰਤੋਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ: ਸਿਸਟਮ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਇੱਕ ਇਵੈਂਟ ਨਵਾਂ ਹੈ, ਡੂਪਲੀਕੇਟ ਹੈ ਜਾਂ ਗੁੰਮ ਹੋ ਗਿਆ। ਇਹ clever ਬਿਲਿੰਗ ਲਾਜਿਕ ਦੀ ਗੱਲ ਨਹੀਂ, ਬਲਕਿ ਇਵੈਂਟ ਪਛਾਣ ਅਤੇ ਵੈਧਤਾ 'ਤੇ ਸਖ਼ਤ ਕੰਟਰੋਲ ਦੀ ਗੱਲ ਹੈ।
Idempotency ਕੀ ਪਹਿਲੀ ਲੀਕ ਦੀ ਰੱਖਿਆ ਹੈ। ਇੱਕ ਚੰਗੀ ਕੀ deterministic ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਹਰ ਬਿਲਿੰਗ ਯੂਨਿਟ ਲਈ ਯੂਨੀਕ—ਉਦਾਹਰਣ: tenant_id + billable_action + source_record_id + time_bucket (ਸਿਰਫ਼ ਜਦੋਂ ਇਕਾਈ ਸਮੇਂ-ਆਧਾਰਿਤ ਹੋ)। ਪਹਿਲੇ ਦਰਮਿਆਨੀ ਲਿਖਤ 'ਤੇ ਇਸਨੂੰ ਯੂਨੀਕ ਨਿਯਮ ਨਾਲ ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਡੂਪਲੀਕੇਟ ਨਹੀਂ ਆ ਸਕਦੇ।
ਰੀਟ੍ਰਾਈਜ਼ ਨਾਰਮਲ ਹਨ—ਇਨ੍ਹਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਨਿਯਮ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਰਿਪీట్ ਸਵੀਕਾਰ ਕਰੋ, ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਦੋ ਵਾਰੀ ਗਿਣੋ ਨਾ। ਇੰਜੈਸਟ ਅਤੇ ਗਿਣਤੀ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ: ਇੱਕ ਵਾਰ ਇੰਗੈਸਟ (idempotent) ਕਰੋ, ਫਿਰ ਸਟੋਰ ਕੀਤੇ ਇਵੈਂਟਸ ਤੋਂ ਏਗ੍ਰਿਗੇਟ ਕਰੋ।
ਵੈਲਿਡੇਸ਼ਨ “ਅਸੰਭਵ ਵਰਤੋਂ” ਨੂੰ ਰੋਕਦੀ ਹੈ:
ਰਿਕਨਸੀਲੇਸ਼ਨ ਚੈਕ ਉਹ ਨਿਰਾਖੇ ਗਾਰਡਰੇਲ ਹਨ ਜੋ “ਅਸੀਂ ਜ਼ਿਆਦਾ ਚਾਰਜ ਕੀਤਾ” ਜਾਂ “ਅਸੀਂ ਵਰਤੋਂ ਗੁਆਈ” ਨੂੰ ਗਾਹਕ ਤੋਂ ਪਹਿਲਾਂ ਪਕੜ ਲੈਂਦੇ ਹਨ।
ਆਰੰਭ ਕਰੋ ਇਹੋ ਜਿਹੇ ਵਿੰਡੋ ਨੂੰ ਦੋ ਥਾਵਾਂ ਤੋਂ ਰਿਕਨਸਾਇਲ ਕਰਕੇ: ਰਾ-ਈਵੈਂਟਸ ਅਤੇ ਏਗ੍ਰਿਗੇਟਿਡ ਉਪਯੋਗ। ਇੱਕ ਨਿਰਧਾਰਤ ਵਿੰਡੋ ਚੁਣੋ (ਉਦਾਹਰਣ: ਕੱਲ੍ਹ ਦਿਨ UTC ਵਿੱਚ) ਅਤੇ ਗਿਣਤੀਆਂ, ਜੋੜਾਂ ਅਤੇ ਯੂਨੀਕ IDs ਨੂੰ ਤુલਨਾ ਕਰੋ। ਛੋਟੇ ਫ਼ਰਕ ਆ ਸਕਦੇ ਹਨ (ਦੇਰ ਨਾਲ ਆਏ ਇਵੈਂਟ, ਰੀਟ੍ਰਾਈਜ਼), ਪਰ ਉਹ ਜਾਣੇ-ਮਾਣੇ ਨਿਯਮਾਂ ਨਾਲ ਸਮਝਾਏ ਜਾ ਸਕਣੇ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਰਹਸਮਈ।
ਫਿਰ, ਜੋ ਤੁਸੀਂ ਬਿਲ ਕੀਤਾ ਉਸਨੂੰ ਜੋ ਤੁਸੀਂ ਪ੍ਰਾਈਸ ਕੀਤਾ ਹੈ ਨਾਲ ਮਿਲਾਓ। ਇਕ ਇਨਵਾਇਸ ਨੂੰ ਇੱਕ ਪ੍ਰਾਈਸ ਕੀਤੀ ਹੋਈ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਦੁਬਾਰਾ ਉਤਪਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਸਹੀ ਉਪਯੋਗ ਟੋਟਲ, ਸਹੀ ਪ੍ਰਾਈਸ ਨਿਯਮ, ਸਹੀ ਕਰੰਸੀ, ਅਤੇ ਸਹੀ ਗੋਲਿੰਗ। ਜੇ ਇਨਵਾਇਸ ਦੁਬਾਰਾ ਚਲਾਕੇ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇਨਵਾਇਸ ਨਹੀਂ, ਇੱਕ ਅਨੁਮਾਨ ਹੈ।
ਰੋਜ਼ਾਨਾ ਸੈਨਿਟੀ ਚੈਕਸ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਫੜ ਲੈਂਦੇ ਹਨ:
ਬਹੁਤ ਸਾਰੇ ਬਿਲਿੰਗ ਆਗਨੀ ਸਧਾਰਨ ਗਲਤ ਧਾਰਾਵਾਂ ਕਰਕੇ ਹੁੰਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਸਮੇਂ ਸੱਚਾਈ ਇੱਕ ਚੀਜ਼ ਚੁਣਨ ਅਤੇ ਉਸਦੇ ਉੱਤੇ ਅਡਿੱਠ ਰਹਿਣ ਵਿੱਚ ਹੈ—ਸਮਾਂ, ਪਛਾਣ ਅਤੇ ਨਿਯਮ।
ਪੇਚੀਦਗੀ ਪੈਦਾ ਕਰਨ ਵਾਲੀਆਂ ਆਮ ਟ੍ਰੈਪਸ:
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ: ਇੱਕ ਗਾਹਕ Acme Co ਨੂੰ ਤਿੰਨ ਮੀਟਰਾਂ 'ਤੇ ਬਿਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: API calls, storage (GB-days), ਅਤੇ premium feature runs.
ਤੁਹਾਡੇ ਐਪ ਇੱਕ ਦਿਨ (5 ਜਨਵਰੀ) ਦੌਰਾਨ ਇਹ ਇਵੈਂਟ ਜਾਰੀ ਕਰਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਉਹ ਫੀਲਡ ਜੋ ਪਹਿਲਾਂ ਕਹਾਣੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ: event_id, customer_id, occurred_at, meter, quantity, ਅਤੇ ਇੱਕ idempotency key.
ਇਨਵਾਇਸ ਚਾਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੀ ਉਪਯੋਗ ਪ੍ਰਣਾਲੀ ਨੂੰ ਇੱਕ ਛੋਟੀ ਵਿੱਤੀ ਖਾਤੇ ਦੀ ਤਰ੍ਹਾਂ ਸਮਝੋ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਕੱਚੇ ਡਾਟਾ ਨੂੰ ਰੀਪਲੇ ਕਰਕੇ ਇੱਕੋ ਟੋਟਲ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ “ਅਸੰਭਵ” ਚਾਰਜਾਂ ਦੇ ਪਿੱਛੇ ਰਾਤਾਂ ਗੁਜਾਰੋਂਗੇ।
ਆਖਰੀ ਗੇਟ ਲਈ ਇਹ ਚੈੱਕਲਿਸਟ ਵਰਤੋ:
ਪਹਿਲੀ ਰੀਲੀਜ਼ ਨੂੰ ਇੱਕ ਪਾਇਲਟ ਵਜੋਂ ਲਓ। ਇੱਕ ਬਿਲਿੰਗ ਯੂਨਿਟ (ਜਿਵੇਂ “API calls” ਜਾਂ “GB stored”) ਅਤੇ ਇੱਕ ਰਿਕਨਸੀਲੇਸ਼ਨ ਰਿਪੋਰਟ ਚੁਣੋ ਜੋ ਉਮੀਦ ਕੀਤੀ ਬਿਲਿੰਗ ਨੂੰ ਅਸਲ ਚਾਰਜ ਨਾਲ ਤੁਲਨਾ ਕਰੇ। ਜਦੋਂ ਉਹ ਇੱਕ ਪੂਰੇ ਚੱਕਰ ਲਈ ਸਥਿਰ ਰਹੇ, ਤਦ ਅਗਲਾ ਯੂਨਿਟ ਸ਼ਾਮਿਲ ਕਰੋ।
ਦਿਨ ਇੱਕ ਤੋਂ ਸਪੋਰਟ ਅਤੇ ਫਾਇਨੈਂਸ ਨੂੰ ਸਫਲ ਬਣਾਉਣ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਇੰਟਰਨਲ ਪੇਜ ਦਿਓ ਜੋ ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਦਿਖਾਏ: ਰਾ-ਈਵੈਂਟਸ ਅਤੇ ਇਨਵਾਇਸ 'ਤੇ ਆਉਣ ਵਾਲੇ ਗਿਣਤੀ। ਜਦੋਂ ਗਾਹਕ ਪੁੱਛੇ “ਮੈਨੂੰ ਕਿਉਂ ਚਾਰਜ ਕੀਤਾ ਗਿਆ?”, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਿੰਗਲ ਸਕਰੀਨ ਹੋਵੇ ਜੋ ਇਸਨੂੰ ਮਿੰਟਾਂ 'ਚ ਜਵਾਬ ਦੇ ਸਕੇ।
ਅਸਲ ਪੈਸਾ ਚਾਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਹਕੀਕਤ ਨੂੰ ਰੀਪਲੇ ਕਰੋ। ਸਟੇਜਿੰਗ ਡਾਟਾ ਨਾਲ ਇੱਕ ਪੂਰੇ ਮਹੀਨੇ ਦੀ ਵਰਤੋਂ ਨਕਲ ਕਰੋ, ਏਗ੍ਰਿਗਰੇਟ ਚਲਾਓ, ਇਨਵਾਇਸ ਬਨਾਓ, ਅਤੇ ਕੁਝ ਨੰਮੂਨੇ ਖਾਤਿਆਂ ਲਈ ਹੱਥੋਂ-ਹੱਥ ਗਿਣਤ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਕਾਫ਼ੀ ਫੈਲੀ ਪੈਟਰਨ ਵਾਲੇ ਕੁਝ ਗਾਹਕ ਚੁਣੋ (ਘੱਟ, ਸਪੀਕੀ, ਸਥਿਰ) ਅਤੇ ਯਕੀਨ ਕਰੋ ਕਿ ਉਹਨਾਂ ਦੇ ਟੋਟਲ ਰਾ-ਈਵੈਂਟਸ, ਦੈਨਿਕ ਏਗ੍ਰਿਗਰੇਟਸ ਅਤੇ ਇਨਵਾਇਸ ਲਾਈਨਸ ਦੇ ਅਨੁਕੂਲ ਹਨ।
ਜੇ ਤੁਸੀਂ ਮੀਟਰਿੰਗ ਸੇਵਾ ਖ਼ੁਦ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਵਰਗਾ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਇੱਕ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਇੰਟਰਨਲ ਐਡਮਿਨ UI ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਲਾਜਿਕ ਸਥਿਰ ਹੋਣ 'ਤੇ ਸੋర్స్ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।
ਡੇਰ ਅਤੇ ਔਟ-ਆਫ-ਆਰਡਰ ਇਵੈਂਟਸ ਆਮ ਹਨ। ਇੱਕ ਬਾਰ ਬਿਲਿੰਗ ਪੀਰੀਅਡ ਇਨਵੌਇਸ ਹੋ ਜਾਣ 'ਤੇ ਉਸਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲੋ ਨਾ—ਇਸਦੀ ਜਗ੍ਹਾ ਅਗਲੇ ਇਨਵੌਇਸ ਵਿੱਚ ਸੋਧ ਨੂੰ ਇੱਕ ਏਡਜਸਟਮੈਂਟ ਵਜੋਂ ਦਰਜ ਕਰੋ।
ਫਿਰ ਇਨਵਾਇਸ ਸੰਸਕਰਨ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ: ਇਹ ਦਰਸਾਉਣਾ ਕਿ ਕਿੰਨੇ ਰਾ-ਈਵੈਂਟਸ, ਕਿਹੜੀ ਡੀਡਿਊਪ ਰੂਲ, ਕਿਹੜੀ ਏਗ੍ਰਿਗੇਸ਼ਨ ਕੋਡ ਵਰਜ਼ਨ ਅਤੇ ਕਿਹੜੇ ਪ੍ਰਾਈਸਿੰਗ ਨਿਯਮ ਨੇ ਉਹ ਲਾਈਨ ਬਣਾਈ। ਬਾਅਦ 'ਚ ਜੇ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਵਾਂ ਇਨਵਾਇਸ ਰਿਵੀਜ਼ਨ ਬਣਾਓ—ਚੁਪਚਾਪ ਐਡੀਟ ਨਹੀਂ।
ਗੁੰਮ ਹੋਈ ਵਰਤੋਂ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਨੋਟਿਸ ਕਰਨ ਵਿੱਚ ਹੈ, ਇਸ ਲਈ ਇੰਜੈਸਟ ਐਰਰਜ਼ ਨੂੰ ਪਹਿਲੇ ਦਰਜੇ ਦਾ ਡੇਟਾ ਮਾਨੋ। ਅਸਫਲ ਇਵੈਂਟਸ ਨੂੰ ਵੀ ਸਫਲਾਂ ਵਰਗੇ ਹੀ ਦਿੱਖ ਰੱਖਦੇ ਹੋਏ ਇਕ ਨਿਰਧਾਰਤ ਏਰਰ ਕਾਰਨ ਅਤੇ ਰੀਟ੍ਰਾਈ ਗਿਣਤੀ ਨਾਲ ਸਟੋਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਲੱਭਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਇੱਕ ਬੈਕਫਿਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੋਏਗੀ। ਬੈਕਫਿਲਜ਼ ਇਰਾਦੇ ਨਾਲ ਅਤੇ ਲੌਗ ਕੀਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ—ਕੀ ਬਦਲਾ, ਕਿਹੜੀ ਵਿੰਡੋ, ਕਿਹੜੇ ਗਾਹਕ, ਕਿਸਨੇ ਟਰਿੱਗਰ ਕੀਤਾ, ਤੇ ਕਾਰਨ। ਸੋਧਾਂ ਨੂੰ ਅਕਾਉਂਟਿੰਗ ਐਂਟ੍ਰੀ ਵਾਂਗ ਜੋਖੋ, ਚੁਪਚਾਪ ਸੋਧਾਂ ਵਾਂਗ ਨਹੀਂ।
ਇੱਕ ਆਸਾਨ ਵਿਵਾਦ ਵਰਕਫਲੋ ਸਪੋਰਟ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖਦਾ ਹੈ: ਜਦੋਂ ਗਾਹਕ ਇਕ ਚਾਰਜ 'ਤੇ ਸਵਾਲ ਕਰੇ, ਤੁਹਾਨੂੰ ਕੱਚੇ ਇਵੈਂਟਸ ਤੋਂ ਉਸਦਾ ਇਨਵਾਇਸ ਉਸੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਪ੍ਰਾਈਸਿੰਗ ਵਰਜ਼ਨ ਨਾਲ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਇੱਕ ਢੀਠ ਸ਼ਿਕਾਇਤ ਨੂੰ ਇੱਕ ਠੀਕ ਕਰਨ ਯੋਗ ਬੱਗ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਉਦਾਹਰਣ: ਇੱਕ ਗਾਹਕ 20 ਤਾਰੀਖ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਇਵੈਂਟ ਪ੍ਰੋਸੈਸਰ ਇੱਕ ਦਿਨ ਦਾ ਡਾਟਾ ਟਾਈਮਆਊਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਬਿਨਾਂ idempotency ਕੀਜ਼ ਅਤੇ ਨਿਯਮ ਵਰਜ਼ਨਿੰਗ ਦੇ, ਤੁਸੀਂ 19ਵੀਂ ਨੂੰ ਡੂਪਲੀਕੇਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ 1-19 ਨੂੰ ਨਵੀਂ ਦਰ 'ਤੇ ਪ੍ਰਾਈਸ ਕਰ ਸਕਦੇ ਹੋ।
{"event_id":"evt_1001","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1002","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1003","customer_id":"cust_acme","occurred_at":"2026-01-05T10:00:00Z","meter":"storage_gb_days","quantity":42.0,"idempotency_key":"daily_storage_2026-01-05"}
{"event_id":"evt_1004","customer_id":"cust_acme","occurred_at":"2026-01-05T15:40:10Z","meter":"premium_runs","quantity":3,"idempotency_key":"run_batch_991"}
ਮਹੀਨੇ ਦੇ ਅੰਤ 'ਚ, ਤੁਹਾਡਾ ਏਗ੍ਰਿਗੇਸ਼ਨ ਜੌਬ customer_id, meter, ਅਤੇ ਬਿਲਿੰਗ ਪੀਰੀਅਡ ਦੁਆਰਾ ਰਾ-ਈਵੈਂਟਸ ਨੂੰ ਗਰੁੱਪ ਕਰਦਾ ਹੈ। ਜਨਵਰੀ ਲਈ ਟੋਟਲ ਮਹੀਨੇ ਭਰ ਦੇ ਜੋੜ ਹਨ: API calls = 1,240,500; storage GB-days = 1,310.0; premium runs = 68.
ਹੁਣ 2 ਫਰਵਰੀ ਨੂੰ ਇੱਕ ਦੇਰ ਨਾਲ ਆਇਆ ਇਵੈਂਟ ਪਾਉਂਦਾ ਹੈ ਜੋ 31 ਜਨਵਰੀ ਲਈ ਹੈ (ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਆਫਲਾਈਨ ਸੀ)। ਕਿਉਂਕਿ ਤੁਸੀਂ occurred_at ਦੁਆਰਾ ਏਗ੍ਰਿਗੇਟ ਕਰਦੇ ਹੋ (ingest time ਨਹੀਂ), ਜਨਵਰੀ ਟੋਟਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਜਾਂ (a) ਅਗਲੇ ਇਨਵਾਇਸ 'ਤੇ +200 ਏਡਜਸਟਮੈਂਟ ਲਿਖੋ ਜਾਂ (b) ਨੀਤੀ ਦੇ ਅਨੁਸਾਰ ਜਨਵਰੀ ਨੂੰ ਮੁੜ ਜਾਰੀ ਕਰੋ।
ਰਿਕਨਸੀਲੇਸ਼ਨ ਇੱਥੇ ਇੱਕ ਬੱਗ ਫੜਦਾ ਹੈ: evt_1001 ਅਤੇ evt_1002 ਇੱਕੋ idempotency_key (req_7f2) ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੀ ਜਾਂਚ “ਇੱਕ ਬੇਨਤੀ ਲਈ ਦੋ ਬਿਲਿੰਗ ਇਵੈਂਟ” ਨੂੰ ਫਲੈਗ ਕਰਦੀ ਹੈ ਅਤੇ ਇਨਵਾਇਸਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨੂੰ ਡੂਪਲੀਕੇਟ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ ਕਰਦੀ ਹੈ।
ਸਪੋਰਟ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾ ਸਕਦਾ ਹੈ: “ਅਸੀਂ ਇੱਕੋ ਹੀ API ਰਿਕਵੇਸਟ ਨੂੰ ਇੱਕ ਰੀਟ੍ਰਾਈ ਕਾਰਨੋਂ ਦੋ ਵਾਰੀ ਰਿਪੋਰਟ ਕੀਤਾ ਵੇਖਿਆ। ਅਸੀਂ ਡੂਪਲੀਕੇਟ ਉਪਯੋਗ ਨੂੰ ਹਟਾ ਦਿੱਤਾ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਵਾਰ ਹੀ ਚਾਰਜ ਕੀਤਾ ਗਿਆ। ਤੁਹਾਡੇ ਇਨਵਾਇਸ ਵਿੱਚ ਸੋਧ ਸਮੇਤ ਸਹੀ ਟੋਟਲ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।”
ਇੱਕ ਪ੍ਰਯੋਗ: ਇੱਕ ਗਾਹਕ ਚੁਣੋ, ਪਿਛਲੇ 7 ਦਿਨਾਂ ਦੇ ਰਾ-ਈਵੈਂਟਸ ਨੂੰ ਇੱਕ ਸਾਫ-ਡੇਟਾਬੇਸ 'ਚ ਰੀਪਲੇ ਕਰੋ, ਫਿਰ ਉਪਯੋਗ ਅਤੇ ਇੱਕ ਇਨਵਾਇਸ ਜਨਰੇਟ ਕਰੋ। ਜੇ ਨਤੀਜਾ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਡਿਟਰਮਿਨਿਸਟਿਕਸ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਨਾ ਕਿ ਗਣਿਤ ਦੀ।
ਜਦੋਂ ਬਿਲਿੰਗ ਨਿਯਮ ਬਦਲਦੇ ਹਨ, ਖਤਰੇ ਘਟਾਓ ਇਕ ਰੀਲੀਜ਼ ਰੂਟੀਨ ਨਾਲ: