13 ਅਗ 2025·7 ਮਿੰਟ
ਵੰਡ-ਸਿਸਟਮ ਸਿਧਾਂਤ: Kleppmann ਦੇ ਖਿਆਲ SaaS ਸਕੇਲਿੰਗ ਲਈ
ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਭਰੋਸੇਯੋਗ SaaS ਬਣਾਉਣ ਵੇਲੇ ਟੀਮਾਂ ਅੱਸਲੀ ਚੋਣਾਂ ਨਾਲ ਜੁੜੇ ਵੰਡ-ਸਿਸਟਮ ਸਿਧਾਂਤ: ਡੇਟਾ ਫਲੋ, ਕੰਸਿਸਟੈਂਸੀ ਅਤੇ ਲੋਡ ਕੰਟਰੋਲ ਸਪਸ਼ਟ ਕੀਤਾ ਗਿਆ।
ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਭਰੋਸੇਯੋਗ SaaS ਬਣਾਉਣ ਵੇਲੇ ਟੀਮਾਂ ਅੱਸਲੀ ਚੋਣਾਂ ਨਾਲ ਜੁੜੇ ਵੰਡ-ਸਿਸਟਮ ਸਿਧਾਂਤ: ਡੇਟਾ ਫਲੋ, ਕੰਸਿਸਟੈਂਸੀ ਅਤੇ ਲੋਡ ਕੰਟਰੋਲ ਸਪਸ਼ਟ ਕੀਤਾ ਗਿਆ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਵਿਚਾਰ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਇੱਕ SaaS ਨੂੰ ਅਸਲ ਵਰਤੋਂ ਨੂੰ ਸਹਿਰਾਉਣਾ ਪੈਂਦਾ ਹੈ: ਚੋਟੀ ਦਾ ਟ੍ਰੈਫਿਕ, ਗੰਦਾ ਡੇਟਾ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਯੂਜ਼ਰ ਜੋ ਹਰ ਛੋਟੇ ਠੋਕਰੇ ਨੂੰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਇਹ ਓਥੇ ਹੀ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਵਾਲ ਬਦਲ ਜਾਂਦਾ ਹੈ: "ਕੀ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ?" ਤੋਂ "ਕੀ ਇਹ ਲਗਾਤਾਰ ਕੰਮ ਕਰਦਾ ਰਹੇਗਾ?"
ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਨਾਲ, "ਕੱਲ੍ਹ ਚਲਿਆ" ਬੇ ਕਾਰਨ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਅਕਸਰ ਦੇਰ ਨਾਲ ਚਲਦਾ ਹੈ। ਇੱਕ ਗਾਹਕ ਉਹ ਫਾਇਲ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਟੈਸਟ ਡੇਟਾ ਤੋਂ 10x ਵੱਡੀ ਹੈ। ਇੱਕ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਈਡਰ 30 ਸਕਿੰਟ ਲਈ ਠਹਿਰ ਜਾਂਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਜੀਬ ਨਹੀਂ ਹੈ, ਪਰ ਜਦੋਂ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਇਕ ਦੂਜੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਰਿਪਲ ਪ੍ਰਭਾਵ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜਿਆਦਾਤਰ ਜਟਿਲਤਾ ਚਾਰ ਥਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਡੇਟਾ (ਉਹੀ ਫੈਕਟ ਕਈ ਜਗ੍ਹਾਂ ਤੇ ਮੌਜੂਦ ਹੋ ਕੇ ਭਟਕ ਜਾਂਦਾ ਹੈ), ਲੈਟੈਂਸੀ (50 ms ਕਾਲ ਕਦੇ-ਕਦੇ 5 ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ), ਫੇਲਿਅਰ (ਟਾਈਮਆਊਟ, ਆਧੇ-ਅਧੂਰੇ ਅਪਡੇਟ, ਰੀਟ੍ਰਾਈਜ਼), ਅਤੇ ਟੀਮਾਂ (ਵੱਖ-ਵੱਖ ਲੋਕ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਅਲੱਗ ਸ਼ੈਡਿਊਲ 'ਤੇ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹਨ)।
ਇੱਕ ਸਧਾਰਣ ਮਨੋਮਾਡਲ ਮਦਦ ਕਰਦਾ ਹੈ: ਕੰਪੋਨੈਂਟਸ, ਸੁਨੇਹੇ, ਅਤੇ ਸਟੇਟ।
ਕੰਪੋਨੈਂਟ ਕੰਮ ਕਰਦੇ ਹਨ (web app, API, worker, database). ਸੁਨੇਹੇ ਕੰਪੋਨੈਂਟਸ ਵਿਚਕਾਰ ਕੰਮ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ (requests, events, jobs). ਸਟੇਟ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਯਾਦ ਰੱਖਦੇ ਹੋ (orders, user settings, billing status). ਸਕੇਲਿੰਗ ਦਾ ਦਰਦ ਅਕਸਰ ਦੂਹਾਂ ਦੇ ਮੇਲ-ਖੇਤੀ ਦੀ ਵਜ੍ਹਾ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਸੁਨੇਹੇ ਉਸ ਵੇਗੇ ਭੇਜ ਰਹੇ ਹੋ ਜਦੋਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਉਸਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦਾ, ਜਾਂ ਤੁਸੀਂ ਸਟੇਟ ਨੂੰ ਦੋ ਥਾਵਾਂ 'ਤੇ ਅਪਡੇਟ ਕਰ ਰਹੇ ਹੋ ਬਿਨਾਂ ਸਪਸ਼ਟ ਸਰੋਤ-ਅਫ-ਟ੍ਰੂਥ ਦੇ।
ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਬਿਲਿੰਗ ਹੈ। ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਇਕ ਇਨਵੌਇਸ ਬਣਾਉ ਸਕਦਾ ਹੈ, ਈਮੇਲ ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ ਯੂਜ਼ਰ ਦੀ ਯੋਜਨਾ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਲੋਡ 'ਤੇ, ਈਮੇਲ ਸੁਸਤ ਹੋ ਜਾਉਂਦਾ ਹੈ, ਬੇਨਤੀ ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਕਲਾਇੰਟ ਰੀਟ੍ਰਾਈ ਕਰਦਾ ਹੈ, ਅਤੇ ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਇਨਵੌਇਸ ਅਤੇ ਇਕ ਯੋਜਨਾ-ਬਦਲ ਹੈ। ਰਿਲਾਇਬਿਲਟੀ ਦਾ ਕੰਮ ਅਕਸਰ ਇਹ ਰੋਕਣਾ ਹੈ ਕਿ ਇਹ ਦਿਨ-ਰੋਜ਼ ਮੁਸ਼ਕਲਾਂ ਗ੍ਰਾਹਕ-ਸਮਨ ਹੋਣ ਵਾਲੀਆਂ ਬੱਗਜ਼ ਨਾ ਬਣ ਜਾਣ।
ਜ਼ਿਆਦਾਤਰ ਸਿਸਟਮ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬਿਨਾਂ ਸਹਿਮਤੀ ਦੇ ਵਧਦੇ ਹਨ ਕਿ ਕੀ ਸਹੀ ਹੋਣਾ ਹੈ, ਕੀ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੀ ਫੇਲ ਹੋਣ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ।
ਸ਼ੁਰੂ ਕਰੋ ਇਸ ਹੱਦੇ ਨੂੰ ਖਿੱਚ ਕੇ ਜੋ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨਾਲ ਵਾਅਦਾ ਕਰ ਰਹੇ ਹੋ। ਉਸ ਹੱਦੇ ਦੇ ਅੰਦਰ ਉਹ ਕਾਰਵਾਈਆਂ ਨਾਮੋ ਹਨ ਜੋ ਹਰ ਵਾਰੀ ਸਹੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਪੈਸਾ-ਮੁਵਮੈਂਟ, ਐਕਸੈਸ ਕੰਟਰੋਲ, ਅਕਾਊਂਟ ਮਾਲਕੀ)। ਫਿਰ ਉਹ ਖੇਤਰ ਨਾਮੋ ਜਿੱਥੇ "ਆਖ਼ਿਰਕਾਰ ਠੀਕ" ਠੀਕ ਹੈ (ਐਨਾਲਿਟਿਕਸ ਕਾਊਂਟਰ, ਖੋਜ ਇੰਡੈਕਸ, ਰਿਕਮੇਨਡੇਸ਼ਨ)। ਇਹ ਇੱਕ ਵੰਡ ਧੁੰਦਲੇ ਸਿਧਾਂਤ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਅਗਲਾ, ਆਪਣਾ ਸਰੋਤ-ਅਫ-ਟ੍ਰੂਥ ਲਿਖੋ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੱਥ ਇਕ ਵਾਰੀ, ਦੂਰਸਤ, ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਨਾਲ ਦਰਜ ਹੁੰਦਾ ਹੈ। ਬਾਕੀ ਸਬ ਕੁਝ ਡੇਰਾਈਵਡ ਡੇਟਾ ਹੈ ਜੋ ਤੇਜ਼ੀ ਜਾਂ ਸੁਵਿਧਾ ਲਈ ਬਣਾਇਆ ਗਿਆ। ਜੇ ਕੋਈ ਡਿਰਾਈਵਡ ਵਿਊ ਕਰੋਪਟ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸਨੂੰ ਸਰੋਤ-ਅਫ-ਟ੍ਰੂਥ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਟੀਮ ਫਸ ਜਾਂਦੀ ਹੈ, ਇਹ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਜੇ ਯੂਜ਼ਰ ਆਪਣੀ ਬਿਲਿੰਗ ਯੋਜਨਾ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਡੈਸ਼ਬੋਰਡ ਦੇਰ ਨਾਲ ਪਿੱਛੇ ਰਹਿ ਸਕਦਾ ਹੈ। ਪਰ ਤੁਸੀਂ ਭੁਗਤਾਨ ਸਥਿਤੀ ਅਤੇ ਵਾਸਤਵਿਕ ਐਕਸੈਸ ਵਿਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋਏ ਵਿਭਿੰਨਤਾ ਸੋਹਣੀ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਜੇ ਯੂਜ਼ਰ ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਨਤੀਜਾ ਦੇਖਣਾ ਜਰੂਰੀ ਹੈ (ਪ੍ਰੋਫ਼ਾਈਲ ਸੇਵ, ਡੈਸ਼ਬੋਰਡ ਲੋਡ, ਪਰਮੀਸ਼ਨ ਚੈੱਕ), ਇੱਕ ਆਮ request-response API ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਸਿੱਧਾ ਰੱਖੋ।
ਜਿਵੇਂ ਹੀ ਕੰਮ ਬਾਅਦ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ async ਵਿੱਚ ਲਿਜਾਓ। ਸੋਚੋ: ਈਮੇਲ ਭੇਜਣਾ, ਕਾਰਡ ਚਾਰਜ ਕਰਨਾ, ਰਿਪੋਰਟ ਜਨਰੇਟ ਕਰਨਾ, ਅਪਲੋਡ ਰੀਸਾਈਜ਼ ਕਰਨਾ, ਜਾਂ ਸਰਚ ਨਾਲ ਡੇਟਾ ਸਿੰਕ ਕਰਨਾ। ਯੂਜ਼ਰ ਨੂੰ ਇਹਨਾਂ ਲਈ ਉਡੀਕ ਨਹੀਂ करनी ਚਾਹੀਦੀ, ਅਤੇ ਤੁਹਾਡੀ API ਨੂੰ ਉਹਨਾਂ ਚੱਲਣ ਵੇਲੇ ਬੰਨ੍ਹਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਕਿੂ ਇੱਕ TODO ਲਿਸਟ ਹੈ: ਹਰ ਟਾਸਕ ਨੂੰ ਇੱਕ ਵਰਕਰ ਦੁਆਰਾ ਇੱਕ ਵਾਰੀ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸਟ੍ਰੀਮ (ਜਾ ਲੌਗ) ਇੱਕ ਰਿਕਾਰਡ ਹੈ: ਇਵੈਂਟ ਕ੍ਰਮਵਾਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕਿ ਕਈ ਰੀਡਰ ਰੀਪਲੇ ਕਰ ਸਕਣ, ਕੈਚ-ਅਪ ਹੋ ਸਕਣ, ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਨਵੇਂ ਫੀਚਰ ਬਣਾਏ ਜਾ ਸਕਣ ਬਿਨਾਂ ਪ੍ਰੋਡੀੂਸਰ ਨੂੰ ਬਦਲੇ।
ਇੱਕ ਪ੍ਰਾਇਗਟਿਕ ਢੰਗ ਚੁਣਨ ਲਈ:
ਉਦਾਹਰਨ: ਤੁਹਾਡੇ SaaS ਵਿੱਚ "Create invoice" ਬਟਨ ਹੈ। API ਇਨਪੁੱਟ ਵੈਰੀਫਾਈ ਕਰਦਾ ਅਤੇ ਇਨਵੌਇਸ ਨੂੰ Postgres ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਫਿਰ ਕਿੂ "send invoice email" ਅਤੇ "charge card" ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਐਨਾਲਿਟਿਕਸ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਫ੍ਰੌਡ ਚੈੱਕ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ InvoiceCreated ਇਵੈਂਟ ਦੀ ਸਟ੍ਰੀਮ ਹਰ ਫੀਚਰ ਨੂੰ ਸਬਸਕ੍ਰਾਈਬ ਕਰਨ ਦਿੰਦੀ ਬਿਨਾਂ ਤੁਹਾਡੇ ਕੋਰ ਸੇਵਾ ਨੂੰ ਭੂਲ-ਭਾਲ ਦਾ ਜਾਲ ਬਣਾਉਣ ਦੇ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਪ੍ਰੋਡਕਟ ਵਧਦਾ ਹੈ, ਇਵੈਂਟ "ਅਚਛਾ ਹੋਣ" ਤੋਂ ਬਦ ਇਨਸਾਨੀ ਸੇਫਟੀ ਨੈੱਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਚੰਗੇ ਇਵੈਂਟ ਡਿਜ਼ਾਈਨ ਦੀ ਮੁੱਖ ਗੱਲ ਦੋ ਸਵਾਲ ਹਨ: ਤੁਸੀਂ ਕਿਹੜੇ ਤੱਥ ਦਰਜ ਕਰਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਹਿੱਸੇ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹਨ?
ਛੋਟੀ ਸੈੱਟ ਦੀਆਂ ਬਿਜ਼ਨਸ ਇਵੈਂਟਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਨ੍ਹਾਂ ਪਲਾਂ ਨੂੰ ਚੁਣੋ ਜੋ ਯੂਜ਼ਰਾਂ ਅਤੇ ਪੈਸੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ: UserSignedUp, EmailVerified, SubscriptionStarted, PaymentSucceeded, PasswordResetRequested.
ਨਾਂਸ ਕੋਡ ਤੋਂ ਲੰਬਾ ਜੀਵਿਤ ਰਹਿੰਦੇ ਹਨ। ਪੂਰਨ ਤੱਥ ਲਈ ਭੂਤਕਾਲੀ ਰੂਪ ਵਰਤੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਰੱਖੋ, ਅਤੇ UI ਸ਼ਬਦਾਂ ਤੋਂ ਬਚੋ। PaymentSucceeded ਅਜੇ ਵੀ ਅਰਥਪੂਰਨ ਰਹਿੰਦਾ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੁਪਨ, ਰੀਟ੍ਰਾਈਜ਼, ਜਾਂ ਕਈ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਈਡਰ ਜੋੜੋ।
ਈਵੈਂਟਸ ਨੂੰ ਕਨਟਰੈਕਟ ਵਜੋਂ ਮੰਨੋ। "UserUpdated" ਵਰਗੇ ਸਭ-ਕੁਝ-ਕਵਰ ਕਰਨ ਵਾਲੇ ਇਵੈਂਟ ਤੋਂ ਬਚੋ ਜਿਸ ਵਿੱਚ ਹਰ ਸਪ੍ਰਿੰਟ ਨਾਲ ਇੱਕ ਗੈਬੈਗ ਫੀਲਡਸ ਹੋ ਜਾਵੇ। ਸਾਲਾਂ ਤੱਕ ਪੱਕਾ ਰਹਿਣ ਲਈ ਸਭ ਤੋਂ ਛੋਟਾ ਤੱਥ ਪਸੰਦ ਕਰੋ ਜਿਸ ਦੇ ਪਿੱਛੇ ਤੁਸੀਂ ਖੜੇ ਹੋ ਸਕੋ।
ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ ਕਰਨ ਲਈ, ਜੋੜ-ਨੂੰ-ਜ਼ਿਆਦਾ ਕਰਨ ਵਾਲੇ ਬਦਲਾਅ ਪਸੰਦ ਕਰੋ (ਨਵੇਂ ਓਪਸ਼ਨਲ ਫੀਲਡ). ਜੇ ਤੁਹਾਨੂੰ ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਨਵਾਂ ਇਵੈਂਟ ਨਾਮ (ਜਾਂ ਸਪਸ਼ਟ ਵਰਜ਼ਨ) ਪਬਲਿਸ਼ ਕਰੋ ਅਤੇ ਜਦ ਤਕ ਪੁਰਾਣੇ ਖਪਤਕਾਰ ਨਹੀਂ ਚਲੇ ਜਾਂਦੇ ਦੋਹਾਂ ਨੂੰ ਚਲਾਉ।
ਕੀ ਤੁਸੀਂ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਵਿੱਚ ਤਾਜ਼ਾ ਰੋਜ਼ਾਂ ਹੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਕਹਾਣੀ ਨੂੰ ਖੋ ਦਿੰਦੇ ਹੋ ਕਿ ਓਥੇ ਕਿਵੇਂ ਪਹੁੰਚਿਆ ਗਿਆ।
ਰਾਲ ਇਵੈਂਟ ਆਡਿਟ, ਰੀਪਲੇ ਅਤੇ ਡਿਬੱਗ ਲਈ ਵਧੀਆ ਹਨ। ਸਨੇਪਸ਼ਾਟ ਤੇਜ਼ ਪੜ੍ਹਾਈ ਅਤੇ ਤੁਰੰਤ ਬਹਾਲੀ ਲਈ ਵਧੀਆ ਹਨ। ਬਹੁਤੇ SaaS ਉਤਪਾਦ ਦੋਹਾਂ ਵਰਤਦੇ ਹਨ: ਕਿਊਂਕਿ ਕੁੰਜੀ ਵਰਕਫ਼ਲੋਜ਼ (ਬਿਲਿੰਗ, ਪਰਮੀਸ਼ਨ) ਲਈ ਰਾਲ ਇਵੈਂਟ ਰੱਖੋ ਅਤੇ ਯੂਜ਼ਰ-ਦੇਖਣ ਵਾਲੇ ਸਕਰੀਨਾਂ ਲਈ ਸਨੇਪਸ਼ਾਟ ਬਣਾਓ।
ਕੰਸਿਸਟੈਂਸੀ ਅਜਿਹੇ ਪਲਾਂ ਤੇ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: "ਮੈਂ ਆਪਣੀ ਯੋਜਨਾ ਬਦਲੀ, ਫਿਰ ਵੀ Free ਕਿਉਂ ਦਿਖਾ ਰਹੀ ਹੈ?" ਜਾਂ "ਮੈਨੂੰ ਇਕ ਇਨਵਾਈਟ ਭੇਜੀ, ਫਿਰ ਮੇਰਾ ਟੀਮ-ਮੈਂਬਰ ਅਜੇ ਤੱਕ ਲੌਗਿਨ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ?"
ਮਜ਼ਬੂਤ ਕੰਸਿਸਟੈਂਸੀ ਮਤਲਬ ਹੈ ਕਿ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਫਲਤਾ ਦਾ ਸੁਨੇਹਾ ਮਿਲੇ, ਤਾਂ ਹਰ ਸਕਰੀਨ ਨਵੇਂ ਸਟੇਟ ਨੂੰ ਤੁਰੰਤ ਦਰਸਾਏ। ਆਖ਼ਰੀਕਰ ਤੌਰ 'ਤੇ ਕੰਸਿਸਟੈਂਸੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਦਲਾਅ ਸਮੇਂ ਦੇ ਨਾਲ ਫੈਲਦਾ ਹੈ, ਅਤੇ ਛੋਟੀ ਖਿੜਕੀ ਲਈ ਐਪ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਗੱਲਬਾਤ 'ਚ ਅਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ "ਵਧੀਆ" ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਉਹ ਚੁਣਦੇ ਹੋ ਜੋ ਮਿਸਮੇਚ ਤੋਂ ਹੋਣ ਵਾਲੇ ਨੁਕਸਾਨ ਦੇ ਆਧਾਰ ਤੇ ਠੀਕ ਲੱਗੇ।
ਮਜ਼ਬੂਤ ਕੰਸਿਸਟੈਂਸੀ ਆਮ ਤੌਰ 'ਤੇ ਪੈਸਾ, ਐਕਸੈਸ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਮੈਚ ਖਾਂਦੀ ਹੈ: ਕਾਰਡ ਚਾਰਜ ਕਰਨਾ, ਪਾਸਵਰਡ ਬਦਲਣਾ, API ਕੀ ਰੱਦ ਕਰਨਾ, ਸੀਟ ਲਿਮਿਟ ਲਾਗੂ ਕਰਨਾ। ਆਖ਼ਰੀਕਰ ਤੌਰ ਤੇ ਕੰਸਿਸਟੈਂਸੀ ਅਕਸਰ ਐਕਟਿਵਿਟੀ ਫੀਡ, ਖੋਜ, ਐਨਾਲਿਟਿਕਸ ਡੈਸ਼ਬੋਰਡ, "last seen", ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਈ ਫਿੱਟ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਟੇਲਨੈੱਸ ਕਬੂਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਨਾ ਕਿ ਲੁਕਾਓ। UI ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੋ: ਲਿਖਤ ਤੋਂ ਬਾਅਦ ਇੱਕ "Updating..." ਸਟੇਟ ਦਿਖਾਓ ਜਦ ਤਕ ਪੁਸ਼ਟੀ ਨਾ ਆ ਜਾਵੇ, ਲਿਸਟਾਂ ਲਈ ਮੈਨੂਅਲ ਰਿਫਰੇਸ਼ ਦੇ ਵਿਕਲਪ ਦਿਓ, ਅਤੇ optimistic UI ਸਿਰਫ਼ ਉਦੋਂ ਵਰਤੋ ਜਦੋਂ ਤੁਸੀਂ ਸਹੀ ਤੌਰ 'ਤੇ ਰੋਲ ਬੈਕ ਕਰ ਸਕੋ।
ਰੀਟ੍ਰਾਈਜ਼ ਉਥੇ ਹਨ ਜਿੱਥੇ ਕੰਸਿਸਟੈਂਸੀ ਚਲਾਕ ਹੋ ਜਾਂਦੀ ਹੈ। ਨੈਟਵਰਕ ਡ੍ਰਾਪ ਹੁੰਦੇ ਹਨ, ਕਲਾਇੰਟ ਦੁਬਾਰਾ-ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਅਤੇ ਵਰਕਰ ਰੀਸਟਾਰਟ ਹੁੰਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਓਪਰੇਸ਼ਨਾਂ ਲਈ, ਬੇਨਤੀਆਂ idempotent ਬਣਾਓ ਤਾਂ ਜੋ ਇੱਕੋ ਕਾਰਵਾਈ ਦੁਹਰਾਉਣ ਨਾਲ ਦੋ ਇਨਵੌਇਸ, ਦੋ ਇਨਵਾਇਟ, ਜਾਂ ਦੋ ਰਿਫੰਡ ਨਾ ਬਣਨ। ਆਮ ਤਰੀਕਾ ਹੈ ਹਰ ਐਕਸ਼ਨ ਲਈ idempotency key + ਸਰਵਰ-ਸਾਈਡ ਨੀਤਿ ਜੋ ਦੁਹਰਾਏ ਗਏ ਲਈ ਅਸਲ ਨਤੀਜਾ ਵਾਪਸ ਕਰੇ।
ਬੈਕਪਰੈਸ਼ਰ ਦੀ ਲੋੜ ਉੱਠਦੀ ਹੈ ਜਦੋਂ ਰਿਕਵੇਸਟ ਜਾਂ ਇਵੈਂਟ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੀ ਸੰਭਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਆਉਣ। ਬਿਨਾਂ ਇਸਦੇ, ਕੰਮ ਮੈਮੋਰੀ ਵਿੱਚ ਇਕੱਠਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿੂ ਵਧਦੇ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਧੀਮਾ ਡਿਪੈਂਡੇੰਸੀ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕਦੋਂ ਫੇਲ ਹੋਵੇਗਾ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਤੁਹਾਡਾ ਪ੍ਰੋਡਿਊਸਰ ਗੱਲ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਕੰਜ਼ੀਉਮਰ ਡੁੱਬ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹੋਰ ਕਾਮ ਸਵੀਕਾਰ ਕਰਦੇ ਰਹੇ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਸੁਸਤ ਨਹੀਂ ਹੁੰਦੇ—ਤੁਸੀਂ ਇੱਕ ਚੇਨ-ਰੇਕਸ਼ਨ ਟਰਿੱਗਰ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਟਾਈਮਆਊਟ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਲੋਡ ਨੂੰ ਗੁਣਾ ਕਰਦੇ ਹਨ।
ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨ ਅਕਸਰ ਆਊਟੇਜ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਦੇ ਹਨ: ਬੈਕਲਾਗ ਸਿਰਫ਼ ਵਧਨਾ, ਸਪਾਈਕ ਜਾਂ ਡਿਪਲੋਇਲੱਕ ਤੋਂ ਬਾਅਦ ਲੈਟੈਂਸੀ ਛਲਾਂਗ ਮਾਰਦੀ ਹੈ, ਰੀਟ੍ਰਾਈਜ਼ ਟਾਈਮਆਊਟ ਵਦ੍ਹਦੇ ਹਨ, ਅਣਸੰਬੰਧਤ ਏਂਡਪੌਇੰਟ ਇੱਕ ਧੀਮੇ ਡਿਪੈਂਡੇੰਸੀ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਲਿਮਿਟ ਤੇ ਰਹਿ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਮੋੜ 'ਤੇ ਹੋ, ਤਾਂ ਇਹ ਵੱਜੋਂ ਇੱਕ ਸਪਸ਼ਟ ਨੀਤੀ ਚੁਣੋ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਭਰ ਗਏ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ। ਲਕਸ਼੍ਯ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਚੀਜ਼ ਕਿਸੇ ਵੀ ਕਿਮਤ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕੀਤੀ ਜਾਵੇ, ਬਲਕਿ ਜ਼ਿਊਆੰਦ ਰਹਿਣ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੀਕਵਰ ਕਰਨਾ ਹੈ। ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਾਂ ਦੋ ਨਿਯੰਤਰਣਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀ: ਰੇਟ ਲਿਮਿਟ, ਬਾਊਂਡਿਡ ਕਿੂਜ਼ ਨਾਲ ਸਪਸ਼ਟ ਡ੍ਰਾਪ/ਡਿਲੇ ਨੀਤੀ, ਫੇਲ ਹੋ ਰਹੀਆਂ ਡਿਪੈਂਡੇੰਸੀਜ਼ ਲਈ ਸਰਕਿਟ ਬ੍ਰੇਕਰ, ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਤਾਂ ਜੋ ਇੰਟਰਐਕਟਿਵ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਜਾਬਾਂ ਉੱਤੇ ਹੱਕ ਮਿਲੇ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਦੀ ਰੱਖਿਆ ਕਰੋ: ਕਨੈਕਸ਼ਨ ਪੂਲ ਛੋਟੇ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰੱਖੋ, ਕੁਐਰੀ ਟਾਈਮਆਊਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਮਹਿੰਗੇ ਐਂਡਪੋਇੰਟਾਂ ਉੱਤੇ ਸਖ਼ਤ ਸੀਮਾਵਾਂ ਰੱਖੋ ਜਿਵੇਂ ad-hoc ਰਿਪੋਰਟਾਂ।
ਰਿਲਾਇਬਿਲਟੀ ਸ਼ਾਇਦ ਵੱਡੇ ਰੀਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ। ਇਹ ਅਕਸਰ ਕੁਝ ਫੈਸਲੇ ਹਨ ਜੋ ਫੇਲ ਨੂੰ ਦਿੱਖਯੋਗ, ਸਨਿਆਪਤ ਅਤੇ ਰੀਕਵਰੇਬਲ ਬਣਾਉਂਦੇ ਹਨ।
ਉਹ ਫਲੋਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਭਰੋਸਾ ਕਮਾਉਂਦੇ ਜਾਂ ਖੋ ਦਿੰਦੇ ਹਨ, ਫਿਰ ਫੀਚਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਰੇਲ ਲਗਾਓ:
ਜੇ ਤੁਹਾਡੀ ਟੂਲਿੰਗ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਮਰਥਨ ਕਰਦੀ ਹੈ (Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਉਹਨੂੰ ਆਮ ਰਿਲੀਜ਼ ਅਭਿਆਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ ਨਾ ਕਿ ਕੇਵਲ ਐਮਰਜੈਂਸੀ ਦੇ ਸਮੇਂ।
ਇੱਕ ਛੋਟੇ SaaS ਦੀ ਤਸਵੀਰ ਸੋਚੋ ਜੋ ਟੀਮਾਂ ਨੂੰ ਨਵੇਂ ਗਾਹਕਾਂ ਨੂੰ ਆਨਬੋਰਡ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਫਲੋ ਸਧਾਰਣ ਹੈ: ਯੂਜ਼ਰ ਸਾਇਨਅੱਪ ਕਰਦਾ, ਯੋਜਨਾ ਚੁਣਦਾ, ਭੁਗਤਾਨ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਵੈਲਕਮ ਈਮੇਲ ਨਾਲ ਕੁਝ "ਸ਼ੁਰੂਆਤੀ" ਕਦਮ ਪ੍ਰਾਪਤ ਕਰਦਾ।
ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ, ਸਭ ਕੁਝ ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ ਹੁੰਦਾ: اکاؤنਟ ਬਣਾਓ, ਕਾਰਡ ਚਾਰਜ ਕਰੋ, "paid" ਉੱਤੇ ਫਲਿੱਪ ਕਰੋ, ਈਮੇਲ ਭੇਜੋ। ਇਹ ਤਦ ਤੱਕ ਚੱਲਦਾ ਹੈ ਜਦ ਤੱਕ ਟ੍ਰੈਫਿਕ ਵੱਧਦਾ, ਰੀਟ੍ਰਾਈਜ਼ ਹੁੰਦੇ, ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਸਲੋ ਹੋ ਜਾਂਦੀਆਂ।
ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ, ਟੀਮ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਵੈਂਟਾਂ ਵਿੱਚ ਬਦਲਦੀ ਹੈ ਅਤੇ ਇੱਕ ਐਪੈਂਡ-ਓਨਲੀ ਇਤਿਹਾਸ ਰੱਖਦੀ ਹੈ। ਉਹ ਕੁਝ ਇਵੈਂਟਸ ਪੇਸ਼ ਕਰਦੇ ਹਨ: UserSignedUp, PaymentSucceeded, EntitlementGranted, WelcomeEmailRequested. ਇਸ ਨਾਲ ਆਡਿਟ ਟਰੇਲ ਮਿਲਦਾ ਹੈ, ਐਨਾਲਿਟਿਕਸ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਧੀਮਾ ਕੰਮ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਸਾਈਨਅੱਪ ਨੂੰ ਰੋਕੇ।
ਕੁਝ ਚੋਣਾਂ ਜਿਹੜੀਆਂ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
PaymentSucceeded ਤੋਂ entitlement ਦਿਓ ਇਕ ਸਪੱਸ਼ਟ idempotency key ਦੇ ਨਾਲ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਦੁਬਾਰਾ-ਗ੍ਰਾਂਟ ਨਾ ਕਰੇ।ਜੇ ਭੁਗਤਾਨ ਸਫਲ ਹੈ ਪਰ ਐਕਸੈਸ ਅਜੇ ਤੱਕ ਨਹੀਂ ਮਿਲਿਆ, ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਠੱਗਿਆ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਹੱਲ ਹਰ ਜਗ੍ਹਾ ਪੂਰੀ ਕੰਸਿਸਟੈਂਸੀ ਨਹੀਂ ਹੈ—ਇਹ ਹੈ ਫੈਸਲਾ ਕਰਨਾ ਕਿ ਕੀ ਤੁਰੰਤ ਚਾਹੀਦਾ ਅਤੇ UI 'ਚ ਉਹ ਨਤੀਜਾ ਦਰਸਾਉਣਾ (ਉਦਾਹਰਣ: "Activating your plan") ਜਦ ਤਕ EntitlementGranted ਆ ਨਾ ਜਾਵੇ।
ਖਰਾਬ ਦਿਨ 'ਤੇ, ਬੈਕਪਰੈਸ਼ਰ ਫਰਕ ਬਣਾਉਂਦਾ ਹੈ। ਜੇ ਮਾਰਕੀਟਿੰਗ ਮੁਹਿੰਮ ਦੌਰਾਨ ਈਮੇਲ API ਸਟਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੁਰਾਣਾ ਡਿਜ਼ਾਇਨ ਚੈਕਆਊਟ ਟਾਈਮਆਊਟ ਕਰਦਾ ਅਤੇ ਯੂਜ਼ਰ ਰੀਟ੍ਰਾਈ ਕਰਦੇ, ਜਿਸ ਨਾਲ ਡੁਪਲਿਕੇਟ ਚਾਰਜ ਅਤੇ ਡੁਪਲਿਕੇਟ ਈਮੇਲ ਬਣਦੇ। ਬਿਹਤਰ ਡਿਜ਼ਾਇਨ ਵਿੱਚ ਚੈਕਆਊਟ ਸਫਲ ਹੁੰਦਾ, ਈਮੇਲ ਦੀਆਂ ਬੇਨਤੀਆਂ ਕਿਊ 'ਚ ਲਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ, ਅਤੇ ਇੱਕ ਰੀਪਲੇ ਜੌਬ ਬੈਕਲਾਗ ਨੂੰ ਰੀਕਵਰੀ 'ਤੇ ਨਿਕਾਲ ਦਿੰਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਆਊਟੇਜ ਇਕ ਹੀ ਵੱਡੇ ਬੱਗ ਨਾਲ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਛੋਟੇ ਫੈਸਲਿਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿਚ ਸਮਝਦਾਰੀ ਨਾਲ ਕੀਤੇ ਗਏ ਸਨ ਅਤੇ ਫਿਰ ਆਦਤ ਬਣ ਗਏ।
ਇੱਕ ਆਮ ਜਾਲ ਹੈ ਬਹੁਤ ਜਲਦੀ ਮਾਇਕਰੋਸਰਵਿਸਜ਼ ਵਿੱਚ ਵੰਡਣਾ। ਤੁਸੀਂ ਐਸੇ ਸੇਵਾ ਪਾ ਲੈਂਦੇ ਹੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਮੇਂ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਕਾਲ ਕਰ ਰਹੇ ਹਨ, ਮਾਲਕੀਅਤ ਅਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਲਈ ਪੰਜ ਡਿਪਲੋਇਜ਼ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
ਦੂਜਾ ਜਾਲ ਇਹ ਹੈ ਕਿ "eventual consistency" ਨੂੰ ਇੱਕ ਮੁਫ਼ਤ ਪਾਸ ਸਮਝ ਲਿਆ ਜਾਵੇ। ਯੂਜ਼ਰ ਸ਼ਬਦਾਂ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਇਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਜਦੋਂ ਉਹ Save ਦਬਾਉਂਦੇ ਹਨ ਤਾਂ ਪੰਨਾ ਬਾਅਦ ਵਿੱਚ ਪੁਰਾਣਾ ਨਾ ਦਿਖਾਏ, ਜਾਂ ਇੱਕ ਇਨਵੌਇਸ ਸਥਿਤੀ ਵਾਰ-ਵਾਰ ਨਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਦੇਰ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਫਿਰ ਵੀ ਯੂਜ਼ਰ ਫੀਡਬੈਕ, ਟਾਈਮਆਊਟ, ਅਤੇ ਹਰ ਸਕਰੀਨ ਲਈ "ਅੱਛਾ ਕਾਫ਼ੀ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਲੋੜੀਂਦੀ ਹੈ।
ਹੋਰ ਦੁਹਰਾਉਣ ਵਾਲੇ ਘਟਕ: ਇਵੈਂਟ ਪਬਲਿਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ ਯੋਜਨਾ, ਅਨਬਾਊਂਡ ਰੀਟ੍ਰਾਈਜ਼ ਜੋ ਘਟਨਾ ਦੌਰਾਨ ਲੋਡ ਨੂੰ ਗੁਣਾ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਹਰ ਸੇਵਾ ਨੂੰ ਇੱਕੋ ਹੀ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨਾਲ ਸੀਧਾ ਗੱਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣਾ ਤਾਂ ਕਿ ਇੱਕ ਬਦਲਾਅ ਕਈ ਟੀਮਾਂ ਨੂੰ ਤੋੜ ਦੇਵੇ।
"Production ready" ਉਹ ਫੈਸਲੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ 2 ਵਜੇ ਵੀ ਦਰਸਾ ਸਕੋ। ਸਪਸ਼ਟਤਾ ਚਲਾਕੀ ਤੋਂ ਵਧੀਕ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਆਪਣੀਆਂ ਸਰੋਤ-ਅਫ-ਟ੍ਰੂਥ ਨੂੰ ਨਾਂਮ ਦੇ ਕੇ। ਹਰ ਇੱਕ ਕੁੰਜੀ ਡੇਟਾ ਟਾਈਪ (customers, subscriptions, invoices, permissions) ਲਈ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅੰਤਿਮ ਰਿਕਾਰਡ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਐਪ ਦੋ ਥਾਵਾਂ ਤੋਂ "ਟ੍ਰੂਥ" ਪੜ੍ਹਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਉੱਤਰ ਦਿਖਾਉਣ ਪਾਓਗੇ।
ਫਿਰ ਰੀਟ੍ਰਾਈਜ਼ ਦੇਖੋ। ਹਰ ਮਹੱਤਵਪੂਰਨ ਕਾਰਵਾਈ ਮੁੱਲੀ-ਮੁੱਲੀ ਵਾਰੀ ਦੌਰਾਨ ਦੋ ਵਾਰ ਚੱਲੇਗੀ—ਇਹ ਤਕਲੀਫ ਮੰਨ ਕੇ ਚਲੋ। ਜੇ ਇੱਕੋ ਬੇਨਤੀ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਦੋ ਵਾਰੀ ਆਵੇ, ਤਾਂ ਕੀ ਤੁਸੀਂ ਡੁਪਲਿਕੇਟ ਚਾਰਜ, ਡੁਪਲਿਕੇਟ ਭੇਜ, ਜਾਂ ਡੁਪਲਿਕੇਟ ਬਣਾਉਣ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ?
ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਜੋ ਜ਼ਿਆਦਾਤਰ ਦਰਦਨਾਕ ਫੇਲਾਂ ਫੜ ਲੈਂਦੀ ਹੈ:
ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback (ਜਿਵੇਂ Koder.ai) ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਧਾਰਣ ਰਿਲੀਜ਼ ਆਦਤ ਬਣਾਓ।
ਜਦੋਂ ਤੁਸੀਂ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਨੂੰ ਫੈਸਲਿਆਂ ਦੀ ਛੋਟੀ ਲਿਸਟ ਸਮਝਦੇ ਹੋ, ਤਾਂ ਸਕੇਲਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।
ਅਗਲੇ ਮਹੀਨੇ ਵਿੱਚ ਤੁਸੀਂ ਜੋ 3-5 ਫੈਸਲੇ ਕਰਨਾ ਉਮੀਦ ਕਰਦੇ ਹੋ ਉਹ ਸਧੇ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: "ਕੀ ਅਸੀਂ ਈਮੇਲ ਭੇਜਣਾ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਵਿੱਚ ਲਿਜਾਈਏ?" "ਕੀ ਅਸੀਂ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਟੇਲਡ ਐਨਾਲਿਟਿਕਸ ਕਬੂਲ ਕਰਦੇ ਹਾਂ?" "ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਤੁਰੰਤ ਕੰਸਿਸਟੈਂਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ?" ਇਸ ਲਿਸਟ ਨੂੰ ਪ੍ਰੋਡਕਟ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨਾਲ ਐਲਾਈਨ ਕਰਨ ਲਈ ਵਰਤੋ।
ਫਿਰ ਇਕ ਵਰਕਫਲੇ ਜੋ ਹੁਣ ਸਿੰਕ੍ਰੋਨ ਹੈ ਚੁਣੋ ਅਤੇ ਕੇਵਲ ਉਸਨੂੰ ਆਸਿੰਕ ਵਿੱਚ ਬਦਲੋ। ਰਸੀਪਟ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਰਿਪੋਰਟਾਂ, ਅਤੇ ਫਾਇਲ ਪ੍ਰੋਸੈਸਿੰਗ ਆਮ ਪਹਿਲੇ ਕਦਮ ਹਨ। ਮਾਪੋ ਦੋ ਚੀਜ਼ਾਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ: ਯੂਜ਼ਰ-ਦੇਖਣ ਵਾਲੀ ਲੈਟੈਂਸੀ (ਕੀ ਪੰਨਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋਇਆ?) ਅਤੇ ਫੇਲਿਅਰ ਵਰਤਾਰਾ (ਕੀ ਰੀਟ੍ਰਾਈਜ਼ ਨੇ ਡੁਪਲਿਕੇਟ ਜਾਂ ਗਲਤ ਫੈਲਵਰਿਆ ਬਣਾਇਆ?)
ਜੇ ਤੁਸੀਂ ਇਹ ਬਦਲਾਅ ਤੁਰੰਤ ਨਮੂਨਾ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) React + Go + PostgreSQL SaaS 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰਨ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕਿ ਰੋਲਬੈਕ ਅਤੇ ਸਨੇਪਸ਼ਾਟ ਹੱਥ-ਨਜ਼ਦੀਕ ਰਹਿੰਦੇ ਹਨ। ਨਿਸ਼ਾਨ ਸਧਾਰਣ ਰਹਿੰਦਾ ਹੈ: ਇੱਕ ਸੁਧਾਰ ਸ਼ਿਪ ਕਰੋ, ਅਸਲ ਟ੍ਰੈਫਿਕ ਤੋਂ ਸਿੱਖੋ, ਫਿਰ ਅਗਲਾ ਫੈਸਲਾ ਕਰੋ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਦਾ ਜਵਾਬ ਹੁੰਦਾ ਹੈ "ਕੀ ਅਸੀਂ ਇਹ ਬਣਾ ਸਕਦੇ ਹਾਂ?" ਇੱਕ SaaS ਨੂੰ ਇਹ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ "ਜਦੋਂ ਯੂਜ਼ਰ, ਡੇਟਾ ਅਤੇ ਫੇਲਿਅਰ ਆਉਣ, ਕੀ ਇਹ ਚਲਦਾ ਰਹੇਗਾ?"
ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਹੁਣ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ:
ਉਸ ਹੱਦੇ ਨੂੰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਾਅਦਾ ਕਰਦੇ ਹੋ, ਫਿਰ ਹਰ ਇਕ ਐਕਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵ ਦੇ ਆਧਾਰ 'ਤੇ ਲੇਬਲ ਕਰੋ।
ਸ਼ੁਰੂ ਕਰੋ ਹਰ ਵਾਰੀ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਨਾਲ:
ਫਿਰ ਨਿਸ਼ਾਨ ਲੱਗਾਓ ਖ਼ਤਮ-ਦੀ-ਅੰਤ ਤੌਰ 'ਤੇ ਠੀਕ ਹੋ ਸਕਦਾ ਲਈ:
ਹਰ "ਫੈਕਟ" ਲਈ ਇੱਕ ਥਾਂ ਚੁਣੋ ਜਿਸ ਵਿੱਚ ਉਹ ਇਕ ਵਾਰੀ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅੰਤੀਮ ਮੰਨੀ ਜਾਂਦੀ ਹੈ (ਛੋਟੇ SaaS ਲਈ ਅਕਸਰ Postgres)। ਇਹ ਤੁਹਾਡਾ ਸੋਰਸ ਆਫ਼ ਟਰੂਥ ਹੈ।
ਹਰ ਹੋਰ ਚੀਜ਼ ਤੇਜ਼ੀ ਜਾਂ ਸੁਵਿਧਾ ਲਈ ਡਿਰਾਈਵਡ ਹੁੰਦੀ ਹੈ (ਕੈਸ਼, ਰੀਡ ਮਾਡਲ, ਖੋਜ ਇੰਡੈਕਸ)। ਇਕ ਚੰਗਾ ਟੈਸਟ: ਜੇ ਡਿਰਾਈਵਡ ਡੇਟਾ ਗਲਤ ਹੈ, ਕੀ ਤੁਸੀਂ ਸਰੋਤ ਤੋਂ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਉਸਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ?
ਜਦੋਂ ਯੂਜ਼ਰ ਨੂੰ ਤੁਰੰਤ ਨਤੀਜ਼ਾ ਚਾਹੀਦਾ ਹੋਵੇ ਅਤੇ ਕੰਮ ਛੋਟਾ ਹੋਵੇ ਤਾਂ request-response ਵਰਤੋ।
ਜਦੋਂ ਕੰਮ ਬਾਅਦ ਵਿੱਚ ਹੋ ਸਕਦਾ ਜਾਂ ਧੀਮੇ ਹੋ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ async 'ਚ ਲਿਜਾਓ:
ਆਸਿੰਕ ਤੁਹਾਡੀ API ਨੂੰ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਟਾਈਮਆਊਟਸ ਨੂੰ ਘਟਾਉਂਦਾ ਜੋ ਕਲਾਇੰਟ ਰੀਟ੍ਰਾਈਜ਼ ਨੂੰ ਟਰਿੱਗਰ ਕਰਦੇ ਹਨ।
ਇੱਕ ਕਿੂ ਇੱਕ ਟੂ-ਡੂ ਲਿਸਟ ਹੈ: ਹਰ ਜੌਬ ਨੂੰ ਇੱਕ ਵਰਕਰ ਵੱਲੋਂ ਇੱਕ ਵਾਰੀ ਹੱਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਰੀਟ੍ਰਾਈਜ਼ ਸਮੇਤ).
ਇੱਕ ਸਟ੍ਰੀਮ/ਲੌਗ ਇੱਕ ਇਵੈਂਟ ਰਿਕਾਰਡ ਹੈ: ਘਟਨਾਵਾਂ ਕ੍ਰਮਵਾਰ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਕਈ ਕੰਜੀਮਰ ਰੀਪਲੇ ਕਰ ਸਕਣ ਜਾਂ ਨਵੇਂ ਫੀਚਰ ਬਣਾਉਣ ਲਈ ਕੈਚ-ਅੱਪ ਹੋ ਸਕਣ।
ਪ੍ਰਾਟੀਕਲ ਡਿਫਾਲਟ:
ਮਹੱਤਵਪੂਰਨ ਕਾਰਵਾਈਆਂ ਨੂੰ idempotent ਬਣਾਓ: ਇੱਕੋ ਬੇਨਤੀ ਨੂੰ ਦੋਬਾਰਾ ਕਰਨ 'ਤੇ ਇੱਕੋ ਨਤੀਜਾ ਆਵੇ, ਦੂਜੀ ਚਾਰਜ ਜਾਂ ਦੂਜਾ ਇਨਵਾਏਸ ਨਾ ਬਣੇ।
ਆਮ ਪੈਟਰਨ:
ਅਤੇ ਜਿੱਥੇ ਹੋ ਸਕੇ ਯੂਨੀਕ ਕੰਸਟਰੈਂਟ ਵਰਤੋ (ਜਿਵੇਂ ਇੱਕ ਆਰਡਰ ਲਈ ਇੱਕ ਇਨਵਾਏਸ).
ਛੋਟੇ ਸੈੱਟ ਦੀ ਸਥਿਰ ਬਿਜ਼ਨਸ ਫੈਕਟਸ ਪਬਲਿਸ਼ ਕਰੋ, ਭੂਤਕਾਲੀ ਰੂਪ ਵਿੱਚ ਨਾਮ ਰੱਖੋ, ਜਿਵੇਂ PaymentSucceeded ਜਾਂ SubscriptionStarted.
ਇਵੈਂਟ ਸੁਭਾਵ:
ਇਸ ਨਾਲ ਖਪਤਕਾਰਾਂ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹੇਗੀ।
ਤੁਹਾਡੇ ਪ੍ਰੋਡਿਊਸਰ ਤੇ ਉਪਭੋਗਤਾ ਦਰਮਿਆਨ ਜੇ ਕਾਰਵਾਈਆਂ ਜ਼ਿਆਦਾ ਆ ਰਹੀਆਂ ਹਨ ਤਾਂ ਬੈਕਪਰੈਸ਼ਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਬਿਨਾਂ ਇਸਦੇ, ਮੈਮੋਰੀ ਵਿੱਚ ਕੰਮ ਇਕੱਠਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿੂ ਵਧਦੇ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਧੀਮਾ ਡਿਪੈਂਡੇੰਸੀ (ਅਕਸਰ ਡੇਟਾਬੇਸ) ਬੱਚੇ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰ ਦਿੰਦਾ ਹੈ।
ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨ ਪਹਿਲਾਂ ਹੀ ਦਿੱਖਦੇ ਹਨ: ਬੈਕਲਾਗ ਹਮੇਸ਼ਾ ਵਧਦਾ ਰਹੇ, ਲੈਟੈਂਸੀ ਸਪਾਇਕ ਦੇ ਬਾਅਦ ਛਲਾਂਗ ਮਾਰੇ, ਰੀਟ੍ਰਾਈਜ਼ ਵਧਣ, ਅਣਸੰਬੰਧਤ ਏਂਡਪੌਇੰਟ ਇੱਕ ਸਲੋ ਡਿਪੈਂਡੇੰਸੀ ਨਾਲ ਫੇਲ, ਅਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਲਿਮਿਟ ਤੇ ਬੈਠੇ ਹੋਏ।
ਪਹਿਲੇ ਕੰਟਰੋਲ ਜੋ ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਲਗਾਉਂਦੀਆਂ ਹਨ: ਰੇਟ ਲਿਮਿਟ (ਪ੍ਰਤੀ ਯੂਜ਼ਰ/ਐਪੀਆਈ ਕੀ), ਬੰਢੇ ਹੋਏ ਕਿੂ ਨਾਲ ਸਪਸ਼ਟ ਡ੍ਰਾਪ/ਡਿਲੇ ਨੀਤੀ, ਫੇਲ ਹੋ ਰਹੀਆਂ ਡਿਪੈਂਡੇੰਸੀਜ਼ ਲਈ ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਤਾਂ ਜੋ ਇੰਟਰਐਕਟਿਵ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਜਾਬਾਂ ਉੱਤੇ ਪਹਿਲ ਮਿਲੇ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਦੀ ਰੱਖਿਆ ਕਰੋ: ਕਨੈਕਸ਼ਨ ਪੂਲ ਛੋਟੇ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਰੱਖੋ, ਕੁਐਰੀ ਟਾਈਮਆਊਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਮਹਿੰਗੇ ਐਂਡਪੋਇੰਟਾਂ 'ਤੇ ਸਖ਼ਤ ਸੀਮਾ ਲਗਾਓ।
ਰਿਲਾਇਬਿਲਟੀ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਰੀਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਅਕਸਰ ਕੁਝ ਐਸੇ ਫੈਸਲਿਆਂ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਫੇਲਿਅਰ ਨੂੰ ਦਿਖਾਉਂਦੇ, ਰੁਕਦੇ ਅਤੇ ਰੀਕਵਰਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਥੋੜੇ ਕਦਮ ਜਿਹੜੇ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ:
ਪ੍ਰੋਟੋਟਾਈਪ ਵਿਚ ਸਭ ਕੁਝ ਇਕ ਬੇਨਤੀ ਵਿੱਚ ਹੁੰਦਾ: ਖਾਤਾ ਬਣਾਉਣਾ, ਕਾਰਡ ਚਾਰਜ ਕਰਨਾ, "ਪੇਡ" ਫਲੈਗ ਫਲਿੱਪ ਕਰਨਾ ਅਤੇ ਈਮੇਲ ਭੇਜਣਾ। ਇਹ ਤਦ ਤੱਕ ਚਲਦਾ ਹੈ ਜਦ ਤੱਕ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਵਧਦਾ, ਰੀਟ੍ਰਾਈਜ਼ ਨਹੀਂ ਹੁੰਦੇ, ਜਾਂ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਸਲੋ ਨਹੀਂ ਹੋ ਜਾਂਦੀਆਂ।
ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ, ਟੀਮ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਵੈਂਟਾਂ ਵਿੱਚ ਬਦਲ ਕੇ ਐਪੈਂਡ-ਓਨਲੀ ਹਿਸਟਰੀ ਰੱਖਦੀ ਹੈ: UserSignedUp, PaymentSucceeded, EntitlementGranted, WelcomeEmailRequested. ਇਹ ਆਡਿਟ ਟਰੇਲ ਦਿੰਦਾ, ਐਨਾਲਿਟਿਕਸ ਆਸਾਨ ਹੁੰਦਾ ਅਤੇ ਧੀਮਾ ਕੰਮ ਸਾਈਨਅੱਪ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।
ਮੁੱਖ ਚੋਣਾਂ ਜੋ ਬਹੁਤ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
ਅਧਿਕांश ਆਊਟੇਜ ਇੱਕ ਵੱਡੇ ਬੱਗ ਦੀ ਵਜ੍ਹਾ ਨਾਲ ਨਹੀਂ ਆਉਂਦੇ, ਬਲਕਿ ਛੋਟੇ ਫੈਸਲਿਆਂ ਤੋਂ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਮਾਣੇ ਗਏ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਦਤ ਬਣ ਗਏ।
ਆਮ ਫੇਲ-ਫੈਸਲੇ:
“Production ready” ਉਹ ਫੈਸਲੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਰਾਤ ਦੇ 2 ਵਜੇ ਵੀ ਬਿਆਨ ਕਰ ਸਕੋ। ਸਪਸ਼ਟਤਾ ਚਲਾਕੀ ਤੋਂ ਵਧੀਕ ਹੈ।
ਆਰੰਭ ਕਰੋ ਆਪਣੀਆਂ ਸਰੋਤ-ਅਫ-ਟ੍ਰੂਥ ਨੁੰ ਨਾਂ ਦੇ ਕੇ। ਹਰ ਇੱਕ ਕੁੰਜੀ ਡੇਟਾ ਟਾਈਪ (ਗਾਹਕ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਇਨਵੌਇਸ, ਅਨੁਮਤੀਆਂ) ਲਈ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅੰਤਿਮ ਰਿਕਾਰਡ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਐਪ ਦੋ ਥਾਵਾਂ ਤੋਂ "ਸੱਚ" ਪੜ੍ਹਦਾ ਹੈ ਤਾਂ ਤੁਰੰਤ ਹੀ ਵਿਭਿੰਨ ਉੱਤਰ ਦਿਖਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ।
ਫਿਰ ਰੀਟ੍ਰਾਈਜ਼ ਵੇਖੋ: ਹਰ ਮਹੱਤਵਪੂਰਨ ਕਾਰਵਾਈ ਇੱਕ ਬਾਰ ਤੋਂ ਵੱਧ ਚੱਲੇਗੀ ਇਹ ਮੰਨੋ। ਜੇ ਇੱਕੋ ਬੇਨਤੀ ਦੁਬਾਰਾ ਹਿੱਟ ਹੁੰਦੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਡੁਬਾਰਾ ਚਾਰਜ/ਡੁਬਾਰਾ ਭੇਜ/ਡੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਕਿਵੇਂ ਬਚੋਗੇ?
ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਜੋ ਆਮ ਦਰਦਨਾਕ ਫੇਲ ਨੂੰ ਫੜ ਲੈਂਦੀ ਹੈ:
ਇਹ ਗੱਲ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਸਭ ਇਕੋ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਬਣਾਉਣ।
ਜੇ ਤੁਹਾਡੀ ਟੂਲਿੰਗ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਮਰਥਿਤ ਕਰਦੀ ਹੈ (Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਰਿਲੀਜ਼ ਅਭਿਆਸ ਦਾ ਹਿੱਸਾ ਬਣਾਓ ਨਾ ਕਿ ਸਿਰਫ਼ ਐਮਰਜੈਂਸੀ ਟ੍ਰਿਕ।
PaymentSucceeded ਤੋਂ entitlement ਦੇਣ ਸਮੇਂ ਸਾਫ idempotency key ਰੱਖੋ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਦੁਬਾਰਾ-ਗ੍ਰਾਂਟ ਨਾ ਕਰਨ।ਜੇ ਪੇਮੈਂਟ ਸਫਲ ਹੋ ਜਾਵੇ ਪਰ ਐਕਸેસ ਅਜੇ ਤੱਕ ਨਹੀਂ ਮਿਲਿਆ, ਤਾਂ ਯੂਜ਼ਰ ਨੂਂ ਠੱਗਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਠੀਕ ਕੀਤਾ ਜਾਣਾ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਜਗ੍ਹਾ ਪਰਫੈਕਟ ਕੰਸਿਸਟੈਂਸੀ ਹੋਵੇ, ਸਗੋਂ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੀ ਤੁਰੰਤ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਅਤੇ UI 'ਚ ਇਸਨੂੰ ਦਰਸਾਓ (ਉਦਾਹਰਣ: "Activating your plan" ਜਦ ਤਕ EntitlementGranted ਨਹੀਂ ਆਉਂਦਾ)।
ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ (ਜਿਵੇਂ Koder.ai) ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਧਾਰਣ ਰਿਲੀਜ਼ ਆਦਤ ਬਣਾਓ ਨਾ ਕਿ ਕੇਵਲ ਸੰਕਟ ਸਮੇਂ।