ਕਿਵੇਂ AI ਅਸਪਸ਼ਟ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਬਦਲਦਾ ਹੈ

“ਪ੍ਰਾਂਪਟ ਤੋਂ ਆਰਕੀਟੈਕਚਰ” ਦਾ ਅਸਲ ਮਤਲਬ

ਅਕਸਰ ਇੱਕ "ਧੁੰਦਲਾ ਪ੍ਰਾਂਪਟ" ਸ਼ੁਰੂਆਤ ਦਾ ਆਮ ਸਥਿਤੀ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਵਿਚਾਰ ਇਰਾਦੇ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਨਾਂ ਕਿ ਨਿਰਦੇਸ਼ਕ ਦੇ ਤੌਰ 'ਤੇ: “ਇੱਕ ਗ੍ਰਾਹਕ ਪੋਰਟਲ ਬਣਾਓ,” “AI ਖੋਜ ਜੋੜੋ,” ਜਾਂ “ਇਵੈਂਟਸ ਨੂੰ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਸਟ੍ਰੀਮ ਕਰੋ।” ਲੋਕ ਜਿਹੜਾ ਨਤੀਜਾ ਚਾਹੁੰਦੇ ਹਨ ਉਹ ਜਾਣਦੇ ਹਨ, ਪਰ ਅਜੇ ਤਕ ਬਾਰਡਰ, ਜੋਖ਼ਮ, ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਚੋਣਾਂ ਜਿਹੜੀਆਂ ਇਸਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਵੇਖੋ ਨਹੀਂ।

“ਪ੍ਰਾਂਪਟ ਤੋਂ ਆਰਕੀਟੈਕਚਰ” ਦਾ ਮਤਲਬ ਹੈ ਉਸ ਇਰਾਦੇ ਨੂੰ ਇੱਕ ਤਰਤੀਬਬੱਧ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲਣਾ: ਕੀ ਬਣਾਉਣਾ ਹੈ, ਹਿੱਸੇ ਕਿਵੇਂ ਮਿਲਦੇ ਹਨ, ਡੇਟਾ ਕਿੱਥੇ ਵਹਿੰਦੀ ਹੈ, ਅਤੇ ਕੀ-ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੰਮ ਕਰੇ।

“ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ ਆਰਕੀਟੈਕਚਰ” ਦਾ ਮਤਲਬ

ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ "ਡਾਇਗ੍ਰਾਮ ਹਨ" ਨਹੀਂ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਗੱਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:

• ਭਰੋਸੇਯੋਗਤਾ: ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਸੁਧਰੇਗਾ, ਅਤੇ ਲੋਡ ਹੇਠਾਂ ਕੀ ਹੋਵੇਗਾ
• ਸੁਰੱਖਿਆ: ਪਹੁੰਚ ਕਿਵੇਂ ਕੰਟਰੋਲ ਹੋਵੇਗੀ, ਸਿਕ੍ਰੇਟ ਕਿੱਥੇ ਰੱਖੇ ਜਾਣਗੇ, ਅਤੇ ਧਮਕੀਆਂ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇਗਾ
• ਲਾਗਤ: ਕੀ ਖਰਚ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
• ਚਲਾਉਣਯੋਗਤਾ: ਮਾਨੀਟਰਿੰਗ, ਬੈਕਅੱਪ, ਡਿਪਲੋਇਮੈਂਟ, ਅਤੇ ਰਾਤ ਦੇ 2 ਵਜੇ ਫੇਲਯਰਾਂ ਨੂੰ ਕਿਵੇਂ ਡੀਬੱਗ ਕਰਦੇ ਹੋ

ਕਿੱਥੇ AI ਮਦਦ ਕਰਦਾ ਹੈ—ਅਤੇ ਕਿੱਥੇ ਭੁੱਲਭੁੱਲੈਯਾਂ ਕਰ ਸਕਦਾ ਹੈ

AI ਸ਼ੁਰੂਆਤੀ ਸੋਚ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਿੱਚ ਮਜ਼ਬੂਤ ਹੁੰਦਾ ਹੈ: ਉਮੀਦ-ਵਿਕਲਪ ਆਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ ਪੈਦਾ ਕਰਨਾ, ਆਮ ਪੈਟਰਨ (queues, caches, service boundaries) ਸੁਝਾਉਣਾ, ਗੈਰ-ਕਾਰਜਕ ਲੋੜਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣਾ, ਅਤੇ ਇੰਟਰਫੇਸ ਕੋਨਟ੍ਰੈਕਟ ਜਾਂ ਚੈੱਕਲਿਸਟ ਡਰਾਫਟ ਕਰਨਾ।

AI ਗਲਤ ਦਿਸ਼ਾ ਤੇ ਲੈ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਇਹ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਭਰੋਸੇਯੋਗ ਲੱਗਦਾ ਹੈ ਜੋ ਇਹ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦਾ: ਬਿਨਾਂ ਪ੍ਰਸੰਗ ਦੇ ਤਕਨੀਕਾਂ ਚੁਣਨਾ, ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਨੂੰ ਘੱਟ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ, ਜਾਂ ਉਹ ਪਾਬੰਦੀਆਂ ਛੱਡ ਦੇਣਾ ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਸੰਗਠਨ ਨੂੰ ਪਤਾ ਹਨ (ਕੰਪਲਾਇੰਸ, ਮੌਜੂਦਾ ਪਲੇਟਫਾਰਮ, ਟੀਮ ਦੀ ਹੁਨਰ). ਆਉਟਪੁੱਟ ਨੂੰ ਪ੍ਰਸਤਾਵ ਸਮਝੋ ਜਿਸਨੂੰ ਚੈਲੈਂਜ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਂ ਕਿ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਅੰਤਿਮ ਜਵਾਬ।

ਇਹ ਪੋਸਟ ਕੀ ਕਵਰ ਕਰੇਗੀ ਤੇ ਕੀ ਨਹੀਂ

ਇਹ ਪੋਸਟ ਇੱਕ ਪ੍ਰਯੋਗਿਕ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਵਰਕਫਲੋ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ ਜੋ ਪ੍ਰਾਂਪਟ → ਲੋੜਾਂ → ਅਨੁਮਾਨ → ਵਿਕਲਪ → ਫੈਸਲੇ ਤੱਕ ਜਾਂਦਾ ਹੈ, ਨਾਲ ਉਹ ਟਰੇਡ-ਆਫ਼ ਜੋ ਤੁਸੀਂ ਟ੍ਰੇਸ ਕਰ ਸਕੋ।

ਇਹ ਡੋਮੇਨ ਮਹਿਰਤ, ਵਿਸ਼ਤਾਰਿਤ ਸਾਈਜ਼ਿੰਗ, ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਦੀ ਥਾਂ ਨਹੀਂ ਲਵੇਗੀ—ਅਤੇ ਇਹ ਨਹੀਂ ਦਾਅਵਾ ਕਰਦੀ ਕਿ ਹਰ ਪ੍ਰਾਂਪਟ ਲਈ ਇੱਕ ਹੀ "ਸਹੀ" ਆਰਕੀਟੈਕਚਰ ਹੈ।

ਕਦਮ 1: ਪ੍ਰਾਂਪਟ ਨੂੰ ਸਾਫ਼ ਸਮੱਸਿਆ ਬਿਆਨ ਵਿੱਚ ਬਦਲੋ

ਧੁੰਦਲਾ ਪ੍ਰਾਂਪਟ ਅਕਸਰ ਗੋਲਾਂ ("ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ"), ਹੱਲਾਂ ("microservices ਵਰਤੋ"), ਅਤੇ ਰਾਇਆਂ ("ਇਸਨੂੰ ਤੇਜ਼ ਬਣਾਓ") ਨੂੰ ਮਿਲਾ ਦਿੰਦਾ ਹੈ। ਕੰਪੋਨੈਂਟ ਚਿੱਤਰਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਬਿਆਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਪਰਖਣ ਅਤੇ ਵਿਚਾਰ ਕਰਨ ਲਈ ਕਾਫੀ ਵਿਸ਼ੇਸ਼ ਹੋਵੇ।

ਸਮੱਸਿਆ ਬਿਆਨ (ਕੌਣ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ ਹੁਣ)

ਇੱਕ ਜਾਂ ਦੋ ਵਾਕ ਲਿਖੋ ਜੋ ਮੁੱਖ ਉਪਭੋਗਤਾ, ਉਹ ਕੰਮ ਜੋ ਉਹ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਤਤਕਾਲਤਾ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ।

ਉਦਾਹਰਨ: “Customer support managers ਨੂੰ ਖੁਲੇ ਟਿਕਟ ਅਤੇ SLA ਖਤਰੇ ਦੀ ਇੱਕ ਏਕ-ਦਿੱਖ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਉਹ ਹਰ ਰੋਜ਼ ਕੰਮ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਣ ਅਤੇ ਇਸ ਕਵਾਰਟਰ ਵਿੱਚ ਮਿਸਡ SLA ਘਟਾ ਸਕਣ।”

ਜੇ ਪ੍ਰਾਂਪਟ ਕੋਈ ਅਸਲ ਉਪਭੋਗਤਾ ਨਾਂਹੀਂ ਦਿਖਾਂਦਾ, ਤਾਂ ਇੱਕ ਪੁੱਛੋ। ਜੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਹੁਣ ਕਿਉਂ ਜਰੂਰੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਟਰੇਡ-ਆਫ਼ ਰੈਂਕ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।

ਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ (ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਚੰਗਾ ਹੋ ਗਿਆ)

"ਚੰਗਾ" ਨੂੰ ਮਾਪਯੋਗ ਨਤੀਜਿਆਂ ਵਿੱਚ ਬਦਲੋ। ਉਤਪਾਦ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੰਕੇਤਾਂ ਦੇ ਮਿਸ਼ਰਣ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ।

• ਪ੍ਰੋਡਕਟ: ਮੁੱਖ ਟਾਸਕ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ, ਅਪਨਾਵ ਦਰ, ਏਰਰ ਰੇਟ, ਕਨਵਰਜ਼ਨ, NPS
• ਓਪਰੇਸ਼ਨਲ: p95 ਲੇਟੈਂਸੀ, ਅਪਟਾਈਮ ਟਾਰਗਟ, ਰਿਕੁਐਸਟ-ਪ੍ਰਤੀ ਲਾਗਤ, ਓਨ-ਕਾਲ ਪੇਜਜ਼/ਹਫਤਾ

3–5 ਛੋਟੇ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ। ਬਹੁਤ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਭ੍ਰਮ ਪੈਦਾ ਕਰਦੇ ਹਨ; ਬਹੁਤ ਘੱਟ ਜੋਖ਼ਮ ਲੁਕਾਉਂਦੇ ਹਨ।

ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਅਤੇ ਮੁੱਖ ਫਲੋਜ਼

ਸਰਲ ਭਾਸ਼ਾ ਵਿੱਚ "ਖੁਸ਼ ਰਾਹ" ਵਰਣਨ ਕਰੋ, ਫਿਰ ਉਹ ਏਜ ਕੇਸ ਲਿਖੋ ਜੋ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਆਕਾਰ ਦੇਣਗੇ।

ਖੁਸ਼ ਰਾਹ ਉਦਾਹਰਣ: ਉਪਭੋਗਤਾ ਸਾਇਨ ਇਨ → ਇੱਕ ਗਾਹਕ ਖੋਜਦਾ ਹੈ → ਮੌਜੂਦਾ ਸਥਿਤੀ ਵੇਖਦਾ ਹੈ → ਫੀਲਡ ਅਪਡੇਟ ਕਰਦਾ ਹੈ → ਆਡਿਟ ਲੌਗ ਦਰਜ ਹੁੰਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਏਜ ਕੇਸ ਜੋ ਸਾਹਮਣੇ ਲਿਆਉਣੇ ਜਾਣ: ਅਫਲਾਈਨ/ਘੱਟ ਕੁਨੈਕਟੀਵਟੀ, ਅੰਸ਼ਿਕ ਅਧਿਕਾਰ, ਨਕਲ ਰਿਕਾਰਡ, ਉੱਚ-ਵਾਲਿਊਮ ਇੰਪੋਰਟਸ, ਟਾਈਮਆਊਟ, ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਜਦੋਂ ਕੋਈ ਡਿਪੈਂਡੈਂਸੀ ਡਾਊਨ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।

ਬਾਹਰ-ਦੇ-ਦਾਇਰੇ (design creep ਰੋਕਣ ਲਈ)

ਉਹ ਚੀਜ਼ਾਂ ਜਿਹੜੀਆਂ ਤੁਸੀਂ ਇਸ ਵਰਜ਼ਨ ਵਿੱਚ ਨਹੀਂ ਬਣਾਉਣਗੇ ਸਪੱਸ਼ਟ ਕਰੋ: ਇੰਟੈਗਰੇਸ਼ਨ ਜੋ ਤੁਸੀਂ ਹੁਣ ਨਹੀਂ ਸਮਰਥਨ ਕਰੋਗੇ, ਅਡਵਾਂਸਡ ਐਨਾਲਿਟਿਕਸ, ਮਲਟੀ-ਰੀਜਨ, ਕਸਟਮ ਵਰਕਫਲੋਜ਼, ਜਾਂ ਪੂਰਾ ਐਡਮਿਨ ਟੂਲਿੰਗ। ਸਪੱਸ਼ਟ ਸਰਹੱਦਾਂ ਸ਼ਡਿਊਲਾਂ ਦੀ ਰਕਸ਼ਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਦੀਆਂ "ਫੇਜ਼ 2" ਗੱਲਬਾਤ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਇਨ੍ਹਾਂ ਚਾਰ ਟੁਕੜਿਆਂ ਨੂੰ ਲਿਖ ਲੈਣ ਤੋਂ ਬਾਦ, ਪ੍ਰਾਂਪਟ ਇੱਕ ਸਾਂਝਾ ਠੇਕੇਦਾਰੀ ਬਣ ਜਾਂਦਾ ਹੈ। AI ਇਸਨੂੰ ਸੰਵਾਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹਨੂੰ ਖੁਦ ਤੋਂ ਨਿਰਮਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।

ਕਦਮ 2: ਲੋੜਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨਿਕਾਲੋ

ਧੁੰਦਲੇ ਪ੍ਰਾਂਪਟ ਅਕਸਰ ਗੋਲ ("ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਓ"), ਫੀਚਰ ("ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜੋ"), ਅਤੇ ਪਸੰਦਾਂ ("serverless ਵਰਤੋ") ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਕਦਮ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਲੋੜਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ।

ਕਾਰਜਕ ਲੋੜਾਂ (ਇਹ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ)

ਸਪਸ਼ਟ ਵਰਤੋਂ-ਯੋਗ ਵਰਤੋਂਵਨੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਨਾਲ ਜੁੜੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪਲੱਟੋ:

• ਫੀਚਰ: ਉਪਭੋਗਤਾ ਰਜਿਸਟਰ/ਲੌਗਿਨ, ਖੋਜ, ਚੈਕਆਉਟ, ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ, ਆਡਿਟ ਲੌਗ
• ਡੇਟਾ: ਤੁਸੀਂ ਕੀ ਸਟੋਰ ਕਰਦੇ ਹੋ (ਉਪਭੋਗਤਾ, ਆਰਡਰ, ਇਵੈਂਟ), ਕਿੰਨੀ ਦੇਰ ਲਈ ਰੱਖਦੇ ਹੋ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ
• ਇੰਟੈਗਰੇਸ਼ਨ: ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਇਡਰ, ਈਮੇਲ/SMS, CRM, ਐਨਾਲਿਟਿਕਸ, ਮੌਜੂਦਾ ਅੰਤਰਿਕ API

ਇੱਕ ਚੰਗੀ ਜਾਂਚ: ਕੀ ਤੁਸੀਂ ਹਰ ਲੋੜ ਲਈ ਕਿਸੇ ਸਕਰੀਨ, API ਐਂਡਪੌਇੰਟ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰ ਸਕਦੇ ਹੋ?

ਗੈਰ-ਕਾਰਜਕ ਲੋੜਾਂ (ਇਹ ਕਿੰਨਾ ਚੰਗਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ)

ਇਹ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਧੁੰਦਲੇ ਸ਼ਬਦਾਂ ਨੂੰ ਮਾਪਯੋਗ ਟਾਰਗਟ ਵਿੱਚ ਬਦਲੋ:

• ਲੇਟੈਂਸੀ: “ਪੰਨੇ ਤੇਜ਼ ਲੋਡ ਹੋਣ” → “95% ਰਿਕਵੈਸਟ 300ms ਦੇ ਥੱਲੇ”
• ਅਪਟਾਈਮ: “ਸਦਾ ਉਪਲਬਧ” → “99.9% ਮਾਸਿਕ ਅਪਟਾਈਮ”
• ਪ੍ਰਾਈਵੇਸੀ/ਕੰਪਲਾਇੰਸ: “EU ਗ੍ਰਾਹਕ ਸੰਭਾਲੋ” → “GDPR ਮੁਢਲੇ: deletion ਬੇਨਤੀਆਂ, ਡੇਟਾ ਐਕਸਪੋਰਟ, ਘੱਟ ਰੀਟੈਨਸ਼ਨ”

ਪਾਬੰਦੀਆਂ (ਜੋ ਤੁਸੀਂ ਬਦਲ ਨਹੀਂ ਸਕਦੇ)

ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੀਮਾਵਾਂ ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੋਈ ਅਦ੍ਰਸ਼ਟ ਆਦਰਸ਼ ਸਿਸਟਮ ਬਣਾਉਣ ਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿਓ ਜੋ ਕਿਸੇ ਨੇ ਸ਼ਿਪ ਨਾ ਕਰ ਸਕੇ:

• ਬਜਟ & ਟਾਈਮਲਾਈਨ: ਫਿਕਸ ਲਾਂਚ ਤਾਰੀਖ, ਕਲਾਉਡ ਖਰਚ ਸੀਮਾਵਾਂ
• ਟੀਮ ਹੁਨਰ: ਮਜ਼ਬੂਤ Python, ਸੀਮਿਤ Kubernetes ਤਜ਼ਰਬਾ
• ਮੌਜੂਦਾ ਸਿਸਟਮ: ਮੌਜੂਦਾ ਡੇਟਾਬੇਸ, SSO, ਜਾਂ ਮੈਸੇਜ ਬੱਸ ਵਰਤਣਾ ਜ਼ਰੂਰੀ

ਸਵੀਕਾਰੋਤਾ ਮਾਪਦੰਡ ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ

ਕੁਝ "done means…" ਬਿਆਨ ਲਿਖੋ ਜੋ ਕੋਈ ਵੀ ਪਰਖ ਸਕੇ, ਉਦਾਹਰਣ:

• “ਨਵਾਂ ਉਪਭੋਗਤਾ ਰਜਿਸਟਰ, ਈਮੇਲ ਪੁਸ਼ਟੀ, ਅਤੇ 2 ਮਿੰਟ ਦੇ ਅੰਦਰ ਲੌਗਿਨ ਕਰ ਸਕਦਾ ਹੈ।”
• “ਸਪੋਰਟ ਇੱਕ ਆਰਡਰ ਨੂੰ ਰੀਫੰਡ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਗ੍ਰਾਹਕ 1 ਮਿੰਟ ਵਿੱਚ ਪੁਸ਼ਟੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।”
• “ਨਿੱਜੀ ਡੇਟਾ ਬੇਨਤੀ 'ਤੇ ਮਿਟਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਬੈਕਅੱਪਸ ਸਮੇਤ 30 ਦਿਨਾਂ ਵਿੱਚ।”

ਇਹ ਲੋੜਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਉਹ ਇਨਪੁੱਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਵਿਰੁੱਧ ਤੁਸੀਂ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਉਮੀਦ-ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ ge।

ਕਦਮ 3: ਅਨੁਮਾਨ ਅਤੇ ਅਣਜਾਣੀਆਂ ਸ਼ੁਰੂ ਹੀ ਸਾਹਮਣੇ ਲਿਆਓ

ਧੁੰਦਲਾ ਪ੍ਰਾਂਪਟ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਫੇਲਦਾ ਨਹੀਂ ਕਿ ਟੈਕਨੋਲੋਜੀ ਮুশਕਲ ਹੈ—ਪਰ ਇਸ ਲਈ ਕਿ ਹਰ ਕੋਈ ਚੁੱਪਚਾਪ ਮੁਕੰਮਲ ਵੇਰਵੇ ਆਪਣੀ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਭਰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, AI ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਗੁਪਤ ਅਨੁਮਾਨਾਂ ਨੂੰ ਖੁੱਲ੍ਹਾ ਕਰੋ ਅਤੇ ਜੋ ਸੱਚ ਹੈ ਉਸਨੂੰ ਅਨੁਮਾਨ ਤੋਂ ਵੱਖ ਕਰ ਦਿਓ।

ਆਮ ਛੁਪੇ ਹੋਏ ਅਨੁਮਾਨ ਜੋ ਲਿਖਣੇ ਚਾਹੀਦੇ ਹਨ

"ਡਿਫਾਲਟ" ਜੋ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਮਾਨ ਲੈਂਦੇ ਹਨ, ਉਹ ਪਹਿਲਾਂ ਲਿਖੋ:

• ਟ੍ਰੈਫਿਕ ਅਤੇ ਵਿਰਧੀ: ਕੀ ਅਸੀਂ 50 ਯੂਜ਼ਰ/ਦਿਨ ਲਈ ਬਣਾ ਰਹੇ ਹਾਂ, ਜਾਂ 50k concurrent users ਲਈ? ਕਿਆ ਉਪਯੋਗਤਾ ਸਪਾਈਕੀ ਹੈ (ਲਾਂਚ ਵਗੈਰਾ) ਜਾਂ ਸਥਿਰ?
• ਡੇਟਾ ਗੁਣਵੱਤਾ: ਕੀ ਆਉਣ ਵਾਲਾ ਡੇਟਾ ਸਾਫ਼ ਅਤੇ ਸੰਰਚਿਤ ਹੈ, ਜਾਂ ਗੁੰਝਲਦਾਰ, ਨਕਲੀਆਂ ਅਤੇ ਗੁੰਮ-ਫਰਮੈੱਟ ਵਾਲਾ ਹੈ?
• ਉਪਭੋਗਤਾ ਵਰਤੋਂ: ਕੀ ਉਪਭੋਗਤਾ ਦੇਰੀ ਸਹਨ ਕਰਦੇ ਹਨ? ਕੀ ਉਹ ਜ਼ੋਰ ਨਾਲ ਰੀਟ੍ਰਾਈ ਕਰਨਗੇ? ਕੀ ਉਹ ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ?
• ਚਲਾਣੇ: ਇਹ ਕਿਸੇ ਨੇ ਸਹਾਰਿਆ ਹੈ? ਕੀ ਓਨ-ਕਾਲ ਕਵਰੇਜ ਹੈ? ਕੀ ਵੀਕੇਂਡ ਆਉਟੇਜ ਸਵੀਕਾਰ ਹੈ?

ਇਹ ਅਨੁਮਾਨ caching, queues, storage, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਲਾਗਤ ਵਰਗੀਆਂ ਚੋਣਾਂ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।

"ਜਾਣੇ ਹੋਏ" vs "ਅਣਜਾਣੇ" vs "ਖੋਜ ਦੀ ਲੋੜ"

AI ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਟੇਬਲ ਜਾਂ ਤਿੰਨ ਛੋਟੀਆਂ ਸੂਚੀਆਂ ਬਣਾਉਣ ਲਈ ਪੁੱਛੋ:

• Knowns: ਪ੍ਰਾਂਪਟ ਜਾਂ ਸਟੇਕਹੋਲਡਰ ਤੋਂ ਪੁਸ਼ਟੀ ਹੋਈ ਲੋੜਾਂ
• Unknowns: ਜਾਂਚ ਬਿਨਾਂ ਫੈਸਲੇ ਰੋਕਣ ਵਾਲੇ ਗੁੰਝਲਦਾਰ ਵੇਰਵੇ
• Needs research: ਸਪਾਈਕਸ, ਵੇਂਡਰ ਚੈੱਕ, ਬੈਂਚਮਾਰਕ, ਕਾਨੂੰਨੀ ਸਮੀਖਿਆ, ਜਾਂ ਯੂਜ਼ਰ ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਵਾਲੇ ਸਵਾਲ

ਇਸ ਨਾਲ AI (ਅਤੇ ਟੀਮ) ਨੂੰ ਗਲਤਫ਼ਹਮੀ ਨੂੰ ਤੱਥ ਸਮਝਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਡਿਜ਼ਾਈਨ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ AI ਨੂੰ ਪੁੱਛਣ ਵਾਲੇ ਸਵਾਲ

ਲਾਭਕਾਰ ਸਵਾਲ ਸ਼ਾਮਿਲ ਹਨ:

• ਸਿਖਰ 3 ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਕੀ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ "ਤੇਜ਼ ਕਿੰਨਾ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ?
• ਕਿਹੜਾ ਡੇਟਾ ਸਟੋਰ ਕਰਨਾ ਹੈ, ਕਿੰਨੀ ਦੇਰ ਲਈ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ?
• ਕਿਹੜੇ ਫੇਲ ਮੋਡ ਸਵੀਕਾਰਯੋਗ ਹਨ (ਅੰਸ਼ਿਕ ਆਊਟੇਜ, ਡਿਲੇਡ ਪ੍ਰੋਸੈਸਿੰਗ, ਰੀਡ-ਓਨਲੀ ਮੋਡ)?
• ਮੌਜੂਦਾ ਇੰਟੈਗਰੇਸ਼ਨ ਕੀ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਰੇਟ-ਲਿਮਿਟਸ/ਭਰੋਸੇਯੋਗਤਾ ਕੀ ਹੈ?
• ਕਿਹੜੀਆਂ ਪਾਬੰਦੀਆਂ ਫਿਕਸ ਹਨ: ਬਜਟ, ਡੈਡਲਾਈਨ, ਕਲਾਉਡ/ਪ੍ਰੋਵਾਇਡਰ, ਕੰਪਲਾਇੰਸ?

ਅਨੁਮਾਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਚੈਲੰਜ ਕੀਤਾ ਜਾ ਸਕੇ

ਅਨੁਮਾਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ ("ਮੰਨ ਲਓ ਪੀਕ 2,000 requests/min","ਮੰਨ ਲਓ PII ਮੌਜੂਦ ਹੈ"). ਉਨ੍ਹਾਂ ਨੂੰ ਡਰਾਫਟ ਇਨਪੁੱਟਾਂ ਵਜੋਂ ਵੇਖੋ—ਸਠਿਕਤਾ ਲਈ ਹਰ ਇੱਕ ਦੇ ਨਾਲ ਉਮਮੀਦਿਤ ਪੁਸ਼ਟੀਕਾਰ ਅਤੇ ਤਾਰੀਖ ਜੋੜੋ। ਇਸ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਬਦਲਾਅ ਨੂੰ ਬਦਲਣਾ ਅਤੇ ਵਿਆਖਿਆ ਕਰਨਾ ਆਸਾਨ ਬਣਦਾ ਹੈ।

ਕਦਮ 4: ਇੱਕ ਜਵਾਬ ਨਹੀਂ—ਕਈ ਉਮੀਦ-ਵਿਕਲਪ ਪੇਸ਼ ਕਰੋ

ਧੁੰਦਲੇ ਪ੍ਰਾਂਪਟ ਕਦੇ ਵੀ ਇੱਕ ਹੀ "ਸਹੀ" ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਦਿੰਦਾ। ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ ਯੋਜਨਾ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਕੁਝ ਯੋਗ ਵਿਕਲਪਾਂ ਦਾ ਖਾਕਾ ਬਣਾਇਆ ਜਾਵੇ, ਫਿਰ ਇੱਕ ਡਿਫਾਲਟ ਚੁਣੋ ਅਤੇ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਕਿਸ ਹਾਲਤ ਵਿੱਚ ਤੁਸੀਂ ਬਦਲੋਂਗੇ।

ਵਿਕਲਪ A (ਪਹਿਲਾਂ ਡਿਫਾਲਟ): ਸਧਾਰਨ ਮੋਨੋਲਿਥ + ਮੈਨੇਜਡ ਸਰਵਿਸਿਜ਼

ਅਕਸਰ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਡਕਟਾਂ ਲਈ, ਇੱਕ ਡਿਪਲੋਏਬਲ ਬੈਕਐਂਡ (API + ਬਿਜ਼ਨਸ ਲੋਜਿਕ), ਇੱਕ ਸਿੰਗਲ ਡੇਟਾਬੇਸ, ਅਤੇ ਕੁਝ ਮੈਨੇਜਡ ਸਰਵਿਸਿਜ਼ (auth, email, object storage) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਨਾਲ ਡਿਪਲੋਇਮੈਂਟ, ਡੀਬੱਗਿੰਗ, ਅਤੇ ਬਦਲਾਵ ਸਿੱਧੇ ਬਣੇ ਰਹਿੰਦੇ ਹਨ।

ਜਦੋਂ ਚੁਣੋ: ਟੀਮ ਛੋਟੀ ਹੋਵੇ, ਲੋੜਾਂ ਬਦਲ ਰਹੀਆਂ ਹੋਣ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਅਨਿਸ਼ਚਿਤ ਹੋਵੇ।

ਵਿਕਲਪ B: ਸਟੈਂਡਰਡ ਮੋਡਿਊਲਰ ਮੋਨੋਲਿਥ + ਐਸਿੰਕ ਜੌਬਸ

ਇੱਕੋ ਡਿਪਲੋਏਬਲ, ਪਰ واضح ਆਂਤਰਿਕ ਮੋਡਿਊਲ (billing, users, reporting) ਅਤੇ ਹੌਲੀ-ਲੰਬੇ ਕੰਮ ਲਈ ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ। ਇੱਕ ਕਿਊ ਅਤੇ ਰੀਟ੍ਰਾਈ ਨੀਤੀਆਂ ਸ਼ਾਮਿਲ ਕਰੋ।

ਜਦੋਂ ਚੁਣੋ: ਤੁਹਾਡੇ ਕੋਲ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਟਾਸਕ ਹਨ, ਪੀਰੀਓਡਿਕ ਸਪਾਈਕ ਹਨ, ਜਾਂ ਮਾਲਕੀਅਤ ਹੱਦਾਂ ਦੀ ਸਪੱਸ਼ਟਤਾ ਦੀ ਲੋੜ ਹੈ—ਬਿਨਾਂ ਸੇਵਾਵਾਂ ਵੰਡਣ ਦੇ।

ਵਿਕਲਪ C: ਸਕੇਲ ਕਰਨਯੋਗ ਸਰਵਿਸਿਜ਼ (ਸਿਰਫ ਜੇ ਲੋੜ ਹੋਵੇ)

ਜਦੋਂ ਕੋਈ ਮਜ਼ਬੂਤ ਐਲਾਨ ਹੋਵੇ (ਕਠੋਰ ਆਈਸੋਲੇਸ਼ਨ/ਕੰਪਲਾਇੰਸ, ਕਿਸੇ ਹਿਸੇ ਨੂੰ ਅਲੱਗ ਸਕੇਲ ਕਰਨ ਦੀ ਲੋੜ), ਕੁਝ ਹਿੱਸਿਆਂ ਨੂੰ ਅਲੱਗ ਸਰਵਿਸਾਂ ਵਿੱਚ ਵੰਡੋ।

ਜਦੋਂ ਚੁਣੋ: ਜੇ ਤੁਸੀਂ ਕੋਈ ਖਾਸ ਲੋਡ ਪੈਟਰਨ, ਆਰਗ ਸੰਰਚਨਾ, ਜਾਂ ਜੋਖ਼ਮ ਪਾਬੰਦੀਆਂ ਦਰਸਾ ਸਕਦੇ ਹੋ ਜੋ ਵਾਧੂ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਨੂੰ ਜ਼ਿਆਦਾ ਕਰਨ ਨੂੰ ਜਾਇਜ਼ ਬਣਾਉਂਦੇ ਹਨ।

ਵਿਕਲਪਾਂ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

ਇਨ੍ਹਾਂ ਵਿਕਲਪਾਂ ਵਿੱਚ ਫਰਕ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ:

• ਕੰਪੋਨੈਂਟ: ਸਿੰਗਲ API ਵਿਰੁੱਧ API + ਵਰਕਰ ਵਿਰੁੱਧ ਕਈ deployables
• ਲਾਗਤ: ਘੱਟ ਹਿੱਸੇ ਵਿਰੁੱਧ ਵੱਧ ਕਿਉਂਕਿ ਕਿਊ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਸਰਵਿਸ-ਟੂ-ਸਰਵਿਸ ਟ੍ਰੈਫਿਕ
• ਜਟਿਲਤਾ: ਸਥਾਨਕ ਵਿਕਾਸ ਲਈ ਆਸਾਨ ਵਿਰੁੱਧ ਹੋਰ ਡਿਪਲੋਇਮੈਂਟ, ਵਰਜ਼ਨਿੰਗ, ਅਤੇ ਫੇਲਯਰ ਮੋਡ

ਚੰਗਾ AI-ਸਹਾਇਤ ਆਉਟਪੁੱਟ ਇੱਕ ਛੋਟਾ ਫੈਸਲਾ ਟੇਬਲ ਹੋਵੇ: “ਡਿਫਾਲਟ = A, B 'ਤੇ ਸਵਿੱਚ ਜੇ ਸਾਡੇ ਕੋਲ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਹਨ, C 'ਤੇ ਜਾਓ ਜੇ X ਮੈਟ੍ਰਿਕ/ਪਾਬੰਦੀ ਸੱਚ ਹੋਵੇ।” ਇਹ ਅਣਛੁਪੇ ਮਾਇਕਰੋਸਰਵਿਸਿਜ਼ ਤੋਂ ਰੋਕਦਾ ਹੈ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਅਸਲੀ ਲੋੜਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ।

ਕਦਮ 5: ਡੇਟਾ ਅਤੇ ਸਰਹੱਦਾਂ ਦਾ ਮਾਡਲ ਬਣਾਓ

ਅਚਾਨਕ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰਾ "ਆਰਕੀਟੈਕਚਰ" ਅਸਲ ਵਿੱਚ ਇਹ ਤੈਅ ਕਰਨਾ ਹੈ ਕਿ ਸਿਸਟਮ ਦਾ ਡੇਟਾ ਕੀ ਹੈ, ਇਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਪਹਿਲਾਂ ਮਾਡਲ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਬਾਅਦ ਦੇ ਕਦਮ (ਕੰਪੋਨੈਂਟ, ਇੰਟਰਫੇਸ, ਸਕੇਲਿੰਗ, ਸੁਰੱਖਿਆ) ਕਾਫੀ ਘੱਟ ਅਟਕਣ ਵਾਲੇ ਹੋ ਜਾਂਦੇ ਹਨ।

ਕੋਰ ਡੋਮੇਨ ਵਸਤੂਆਂ ਨੂੰDEFINE ਕਰੋ (ਅਤੇ ਕੌਣ ਮਾਲਕ ਹੈ)

ਉਹ ਕੁਝ ਵਸਤੂਆਂ ਨਾਮੋ ਜਿਹੜਿਆਂ 'ਤੇ ਸਿਸਟਮ ਗਿਰਦਾ ਹੈ—ਅਕਸਰ ਪ੍ਰਾਂਪਟ ਤੋਂ ਨਾਊਂਸ: User, Organization, Subscription, Order, Ticket, Document, Event ਆਦਿ। ਹਰ ਵਸਤੂ ਲਈ ਮਾਲਕੀਅਤ ਕੈਪਚਰ ਕਰੋ:

• Source of truth: ਕਿਹੜੀ ਸਿਸਟਮ/ਸੇਵਾ ਲਿਖਣ ਦੀ ਆਗਿਆ ਰੱਖਦੀ ਹੈ?
• Readers: ਕੌਣ ਇਸਨੂੰ ਖਾਂਦਾ/ਵਰਤਦਾ ਹੈ (ਹੋਰ ਸੇਵਾਵਾਂ, ਐਨਾਲਿਟਿਕਸ, ਸਪੋਰਟ)?
• Lifecycle: ਬਣਾਉਣਾ/ਅਪਡੇਟ/ਹਟਾਉਣਾ, ਅਤੇ ਕੋਈ "soft delete" ਨਿਯਮ

ਇੱਥੇ AI ਲਾਭਕਾਰੀ ਹੈ: ਇਹ ਪ੍ਰਾਰੰਭਿਕ ਡੋਮੇਨ ਮਾਡਲ ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ ਪ੍ਰਾਂਪਟ ਤੋਂ, ਫਿਰ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਅਸਲ ਹੈ ਜਾਂ ਮੰਨਿਆ ਗਿਆ।

ਐਕਸੇਸ ਜ਼ਰੂਰਤਾਂ ਦੇ ਅਨੁਸਾਰ ਸਟੋਰੇਜ ਪੈਟਰਨ ਚੁਣੋ

ਫੈਸਲਾ ਕਰੋ ਕਿ ਹਰ ਵਸਤੂ ਮੁੱਖ ਤੌਰ 'ਤੇ transactional (OLTP) ਹੈ—ਛੋਟੇ ਪੜ੍ਹਾਈ/ਲਿਖਾਈ ਬਹੁਤ ਹਨ ਜੋ ਸਥਿਰਤਾ ਲਾਜ਼ਮੀ ਹੈ—ਜਾਂ analytical ਹੈ (aggregations, ਰੁਝਾਨ, ਰਿਪੋਰਟਿੰਗ)। ਇੱਕੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਹਨਾਂ ਦੀ ਮਿਲਾਪ ਅਕਸਰ ਟੈਂਸ਼ਨ ਬਣਾਉਂਦੀ ਹੈ।

ਆਮ ਪੈਟਰਨ: ਐਪ ਲਈ OLTP ਡੇਟਾਬੇਸ ਅਤੇ ਇਵੈਂਟਸ ਜਾਂ ਐਕਸਪੋਰਟ ਦੁਆਰਾ ਭਰਿਆ ਇੱਕ ਵੱਖਰਾ ਐਨਾਲਿਟਿਕਸ ਸਟੋਰ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਟੋਰੇਜ ਨੂੰ ਇਸ ਨਾਲ ਅਨੁਕੂਲ ਕਰੋ ਕਿ ਡੇਟਾ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਇਹ ਕਿਵੇਂ "ਲੱਗਦਾ" ਹੈ।

ਡੇਟਾ ਫਲੋ ਸਮੂਹ-ਸੰਪੂਰਕ ਤਰੀਕੇ ਨਾਲ ਯੋਜਨਾ ਬਣਾਓ

ਸਿਸਟਮ ਵਿੱਚ ਡੇਟਾ ਕਿਵੇਂ ਨਿਭਰੇਗਾ:

• Ingestion: APIs, uploads, webhooks, batch imports
• Transformation: validation, enrichment, deduplication
• Retention and deletion: ਡੇਟਾ ਕਿੰਨੀ ਦੇਰ ਰੱਖਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਕਿਵੇਂ ਹਟਾਇਆ ਜਾਵੇਗਾ

ਡੇਟਾ ਜੋਖ਼ਮ ਪਹਿਲਾਂ ਹੀ ਸਾਹਮਣੇ ਲਿਆਂਦੇ ਜਾਣ

ਖਤਰੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ: PII ਸੰਭਾਲ, ਨਕਲ ਰਿਕਾਰਡ, conflicting sources (ਦੋ ਸਿਸਟਮ ਦਾਅਵਾ ਕਰ ਰਹੇ ਹਨ ਕਿ ਉਹ ਸਚ ਹਨ), ਅਤੇ ਅਸਪਸ਼ਟ deletion semantics। ਇਹ ਖਤਰੇ ਸਰਹੱਦ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ: ਕੀ ਅੰਦਰ ਰਹੇਗਾ, ਕੀ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਆਡਿਟ ਟਰੇਲ ਜਾਂ ਪਹੁੰਚ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੈ।

ਕਦਮ 6: ਕੰਪੋਨੈਂਟ ਅਤੇ ਇੰਟਰਫੇਸ ਨਕਸ਼ਾ ਬਣਾਓ

ਜਦੋਂ ਤੁਸੀਂ ਸਰਹੱਦ ਅਤੇ ਡੇਟਾ ਰੱਖ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ठोस ਕੰਪੋਨੈਂਟ ਨਕਸ਼ੇ ਵਿੱਚ ਬਦਲੋ: ਕੀ ਮੌਜੂਦ ਹੈ, ਕੀ ਇਸਦੀ ਮਾਲਕੀ ਹੈ, ਅਤੇ ਇਹ ਹੋਰਾਂ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦਾ ਹੈ। ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ AI ਇੱਕ "ਸ਼ਬਦਾਂ ਵਿੱਚ ਡਾਇਗ੍ਰਾਮ ਜਨਰੇਟਰ" ਵਜੋਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੈ—ਇਹ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਵੱਖਰੇ ਸਮਭਾਗ ਕਿਵੇਂ ਹੋਣ ਅਤੇ ਖੁੰਝੇ ਇੰਟਰਫੇਸ ਕਿੱਥੇ ਗੁਆਚ ਰਹੇ ਹਨ।

ਮੋਡਿਊਲ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਕਮ ਗਿਣਤੀ ਵਾਲੇ ਕੰਪੋਨੈਂਟ ਅਤੇ ਸਾਫ਼ ਮਾਲਕੀਅਤ ਲਈ ਨਿਸ਼ਾਨਾ ਬਣਾਓ। ਇੱਕ ਵਧੀਆ ਜਾਂਚ ਇਹ ਹੈ: "ਜੇ ਇਹ ਟੁੱਟੇ, ਤੇ ਕੋਣ ਠੀਕ ਕਰੇਗਾ ਅਤੇ ਕੀ ਬਦਲੇਗਾ?" ਉਦਾਹਰਣ:

• API Gateway / BFF: ਰਿਕਵੈਸਟ ਰੂਟਿੰਗ, auth enforcement, rate limits
• Core service(s): ਬਿਜ਼ਨਸ ਨਿਯਮ ਅਤੇ ਵਰਕਫਲੋ
• Data store(s): persistence ਅਤੇ query ਪੈਟਰਨ (ਸਿਰਫ਼ "ਇੱਕ ਡੇਟਾਬੇਸ" ਨਹੀਂ)
• Async workers: ਲੰਬੇ-ਚੱਲਦੇ ਟਾਸਕ, retries, scheduled jobs
• Observability: ਲੌਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ, ਟ੍ਰੇਸਿੰਗ (ਪਹਿਲ-ਪੰਜਾਬੇ ਕੰਪੋਨੈਂਟ ਵਜੋਂ)

ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ (ਅਤੇ ਕਿਉਂ)

ਹਰ ਬਣਾਵਟ ਲਈ ਡੀਫਾਲਟ ਸੰਚਾਰ ਅੰਦਾਜ਼ ਚੁਣੋ ਅਤੇ ਅਪਵਿਵੇਕ ਲਈ ਸਬੂਤ ਦਿਓ:

• REST/HTTP ਸਧਾਰਨ request/response ਅਤੇ human-debuggable ਫਲੋਜ਼ ਲਈ
• Events / pub-sub ਜਦੋਂ ਕਈ ਖਪਤਕਾਰ ਇੱਕੋ ਤਬਦੀਲੀ 'ਤੇ ਪ੍ਰਤਿਕਿਰਿਆ ਕਰਦੇ ਹਨ
• Queues ਬੈਕਗ੍ਰਾਊਂਡ ਕੰਮ ਲਈ, ਸਪਾਈਕ ਨੂੰ ਨਰਮ ਕਰਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰੀਟ੍ਰਾਇ ਲਈ

AI ਹਰ ਯੂਜ਼ਕੈਸ ਨੂੰ ਸਭ ਤੋਂ ਸਧਾਰਨ ਇੰਟਰਫੇਸ ਨਾਲ ਮੈਪ ਕਰਕੇ ਲੇਟੈਂਸੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਬਾਹਰੀ ਡਿਪੈਂਡੈਂਸੀ ਅਤੇ ਫੇਲਯਰ ਵਿਹੈਵਿਅਰ

ਤੀਜੀ-ਪੱਖੀ ਸਰਵਿਸਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਉਹ ਫੇਲ ਹੋਣਗੀਆਂ ਤਾਂ ਕੀ ਹੋਵੇਗਾ:

• ਟਾਈਮਆਊਟ, ਰੀਟ੍ਰਾਈਜ਼ ਵਿਥ ਬੈਕਆਫ, ਅਤੇ ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਨੀਤੀਆਂ
• ਡਿਗਰੇਡਡ ਮੋਡ (ਕੈਸ਼ਡ ਡੇਟਾ ਸੇਵਾ ਕਰੋ? ਪੜ੍ਹਨ-ਮਾਤਰ?)
• ਸਪੱਸ਼ਟ ਏਰਰ ਸਮਝੌਤੇ (ਕਲਾਇੰਟਾਂ ਨੂੰ ਕੀ ਉਮੀਦ ਹੋਵੇ)

ਇੰਟੈਗਰੇਸ਼ਨ ਨਕਸ਼ਾ (ਸਿਸਟਮ, APIs, auth)

ਸੰਖੇਪ "ਇੰਟੈਗਰੇਸ਼ਨ ਟੇਬਲ" ਲਿਖੋ:

• Payments → Provider API (REST), OAuth2 client credentials, idempotency keys
• Email/SMS → Messaging API (REST), API key, 5xx 'ਤੇ retry queue
• Analytics → Event stream, service token, overload 'ਤੇ drop-policy

ਇਹ ਨਕਸ਼ਾ ਨਿਰਵਾਹ ਟਿਕਟਾਂ ਅਤੇ ਸਮੀਖਿਆ ਚਰਚਾਵਾਂ ਲਈ ਹੱਡੀ-ਪੀਂਡ ਬਣ ਜਾਂਦਾ ਹੈ।

ਕਦਮ 7: ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਚਿੰਤਾਵਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਕਿਸੇ ਡਿਜ਼ਾਈਨ ਦਾ ਵ੍ਹਾਈਟਬੋਰਡ ਤੇ ਪੇਸ਼ ਕੀਤਾ ਹੋਇਆ ਚਿੱਤਰ ਸੋਹਣਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਦਿਨ-ਇੱਕ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ "ਪ੍ਰੋਡਕਸ਼ਨ ਕਾਂਟਰੈਕਟ" ਸਪੱਸ਼ਟ ਕਰੋ: ਲੋਡ ਹੇਠਾਂ, ਫੇਲਯਰ ਦੌਰਾਨ, ਅਤੇ ਹਮਲੇ ਦੇ ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪਛਾਣੋਗੇ।

ਭਰੋਸੇਯੋਗਤਾ: ਫੇਲਯਰ ਪਾਥਾਂ ਦੀ ਯੋਜਨਾ

ਸਿਸਟਮ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ ਜਦੋਂ ਡਿਪੈਂਡੈਂਸੀ ਸੁਸਤ ਜਾਂ ਡਾਊਨ ਹੋਈ ਹੋਵੇ। ਟਾਈਮਆਊਟ, ਰੀਟ੍ਰਾਈਜ਼ ਵਿਥ ਜਿਟਰ, ਅਤੇ ਸਪੱਸ਼ਟ ਸਰਕਿਟ-ਬ੍ਰੇਕਰ ਨਿਯਮ ਸ਼ਾਮਿਲ ਕਰੋ। ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਆਈਡੈਮਪੋਟੈਂਟ ਬਣਾਓ (ਰੀਕਵੇਸਟ IDs ਜਾਂ idempotency keys ਵਰਤ ਕੇ)।

ਤੀਜੀ-ਪੱਖੀ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਸਮੇਂ ਰੇਟ-ਲਿਮਿਟਸ ਮੰਨੋ ਅਤੇ ਬੈਕਪ੍ਰੈਸ਼ਰ ਬਣਾਓ: ਕਿਊ, ਬਾਊਂਡਿਡ concurrency, ਅਤੇ ਸੁਗਮ ਹਾਲਤ (ਉਦਾਹਰਣ ਲਈ "ਬਾਅਦ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰੋ" ਜਵਾਬ) ਨੂੰ ਤਰਜੀਹ ਦਿਓ।

ਸੁਰੱਖਿਆ: ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਫੈਸਲਾ ਕਰੋ

Authentication (ਕਿਵੇਂ ਯੂਜ਼ਰ ਆਪਣੀ ਪਹਚਾਣ ਦਿਖਾਉਂਦੇ ਹਨ) ਅਤੇ authorization (ਉਹ ਕੀ ਦੇਖ/ਕਰ ਸਕਦੇ ਹਨ) ਨਿਰਧਾਰਤ ਕਰੋ। ਉੱਚ-ਜਰੂਰੀ ਧਮਕੀਆਂ ਲਿਖੋ: ਚੋਰੀ ਹੋਏ ਟੋਕਨ, ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਦਾ ਦੁੱਭਾਅ, ਇੰਪੁੱਟ ਰਾਹੀਂ ਇੰਜੈਕਸ਼ਨ, ਜਾਂ ਪ੍ਰਿਵਿਲੇਜ ਐਸਕਲੇਸ਼ਨ।

ਸਿੱਧਤ ਕਰੋ ਕਿ secrets ਕਿੱਥੇ ਰਹਿਣਗੇ, ਕਿਸ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਆਗਿਆ ਹੈ, ਰੋਟੇਸ਼ਨ ਕਿੰਨੀ ਵਾਰ ਹੋਵੇਗੀ, ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਕਿਵੇਂ ਮਿਲੇਗਾ।

ਪ੍ਰਦਰਸ਼ਨ: ਟਾਰਗਟ, ਨਾ ਕਿ ਧਾਰਣਾ

ਸਕੈਪਸ ਵੀਵੇਕਪੂਰਵਕ ਟਾਰਗਟ ਨਿਰਧਾਰਤ ਕਰੋ। ਫਿਰ ਤਕਨੀਕਾ ਚੁਣੋ: ਕੈਸ਼ਿੰਗ (ਕੀ, ਕਿੱਥੇ, TTL), ਬੈਚਿੰਗ ਲਈ ਚੈਟੀ ਕਾਲਾਂ, ਐਸਿੰਕ ਵਰਕ ਲੰਬੇ ਟਾਸਕਾਂ ਲਈ, ਅਤੇ ਸਾਂਝੇ ਸਰੋਤਾਂ ਦੀ ਰੱਖਿਆ ਲਈ ਹੱਦਾਂ।

ਨਿਰੀਖਣਯੋਗਤਾ: ਜੋ ਨਹੀਂ ਵੇਖ ਸਕਦੇ ਉਹ ਨਹੀਂ ਠੀਕ ਕਰ ਸਕਦੇ

ਸੰਰਚਿਤ ਲੌਗ, ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ (ਲੇਟੈਂਸੀ, ਏਰਰ רੇਟ, ਕਿਊ ਡੈਪਥ), ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਬਾਊਂਡਰੀਆਂ, ਅਤੇ ਬੁਨਿਆਦੀ ਅਲਰਟਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਹਰ ਅਲਰਟ ਨੂੰ ਕਾਰਵਾਈ ਨਾਲ ਜੋੜੋ: ਕੋਣ ਜਵਾਬ ਦੇਵੇਗਾ, ਕੀ ਚੈਕ ਕਰਨਾ ਹੈ, ਅਤੇ "ਸੇਫ ਮੋਡ" ਕੀ ਦਿਖਦਾ ਹੈ।

ਇਹ ਚੋਣਾਂ endpoints ਅਤੇ ਡੇਟਾਬੇਸ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ जितਨੀ ਹੀ ਪਹਿਲ-ਪੰਕਤੀ ਹਨ—ਉਹਨਾਂ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਆਈਟਮ ਵਜੋਂ ਸਮਝੋ।

ਕਦਮ 8: ਟਰੇਡ-ਆਫ਼ ਸਪੱਸ਼ਟ ਅਤੇ ਟ੍ਰੇਸੇਬਲ ਬਣਾਓ

ਆਰਕੀਟੈਕਚਰ ਇੱਕ "ਸਭ ਤੋਂ ਵਧੀਆ" ਉੱਤਰ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਪਾਬੰਦੀਆਂ ਹੇਠਾਂ ਚੋਣਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੁੰਦਾ ਹੈ। AI ਇੱਥੇ ਤਕਨੀਕੀ ਰੂਪ ਵਿੱਚ ਉਪਯੋਗੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਲਪਾਂ ਦੀ सूची ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਰਿਕਾਰਡ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਉਂ ਇੱਕ ਰਸਤਾ ਚੁਣਿਆ, ਕੀ ਤਿਆਗਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਕਿਹੜੀ ਘਟਨਾ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤਾ ਜਾਵੇਗਾ।

ਸਧਾਰਨ ਟਰੇਡ-ਆਫ਼ ਟੇਬਲ ਵਰਤੋ

ਜੋਖ਼ਮ ਕਿੱਥੇ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ ਵਿ. ਸੁਰੱਖਿਅਤ ਕਰਨਾ

"ਸਵੀਕਾਰਯੋਗ ਫੇਲ" (ਉਦਾਹਰਣ: ਕਦੇ-ਕਦੇ ਈਮੇਲ ਦੇਰੀ) ਅਤੇ "ਕਦੇ ਨਹੀਂ ਫੇਲ" ਖੇਤਰ (ਭੁਗਤਾਨ, ਡੇਟਾ ਘਾਟ) ਦਖ਼ਲ ਦਿਓ। ਮਹਿੰਗੇ ਫੇਲਿਆਂ ਲਈ ਸੁਰੱਖਿਅਤੀਆਂ ਲਗਾਓ: ਬੈਕਅੱਪ, ਆਈਡੈਮਪੋਟੈਂਸੀ, ਰੇਟ ਲਿਮਿਟਸ, ਅਤੇ ਸਾਫ਼ ਰੋਲਬੈਕ ਰਾਹ।

ਓਪਰੇਸ਼ਨਲ ਟਰੇਡ-ਆਫ਼ ਜੋ ਟੀਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ

ਕੁਝ ਡਿਜ਼ਾਈਨ ਓਨ-ਕਾਲ ਲੋਡ ਅਤੇ ਡੀਬੱਗਿੰਗ ਮੁਸ਼ਕਲਾਈ ਵਧਾਉਂਦੇ ਹਨ (ਜ਼ਿਆਦਾ ਹਿੱਸੇ, ਜ਼ਿਆਦਾ ਰੀਟ੍ਰਾਈਜ਼, ਵੰਡੇ ਲੌਗ)। ਐਸੇ ਚੋਣਾਂ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਜੋ ਤੁਹਾਡੇ ਸਹਾਇਤਾ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ: ਘੱਟ ਸੇਵਾਵਾਂ, ਸਾਫ਼ ਨਿਰੀਖਣਯੋਗਤਾ, ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਫੇਲ ਮੋਡ।

ਤਕਨੀਕੀ ਟਰੇਡ-ਆਫ਼: ਮੈਨੇਜਡ ਵਿ. ਸੈਲਫ-ਹੋਸਟ

ਫੈਸਲੇ ਲਈ ਮਾਪਦੰਡ ਸਪੱਸ਼ਟ ਕਰੋ: ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ, ਕਸਟਮਾਈਜੇਸ਼ਨ, ਲੇਟੈਂਸੀ, ਅਤੇ ਸੰਚਾਲਨ ਸਟਾਫ਼ਿੰਗ। ਜੇ ਤੁਸੀਂ ਲਾਗਤ ਲਈ self-hosted ਚੁਣਦੇ ਹੋ, ਤਾਂ ਛੁਪੇ ਹੋਏ ਖ਼ਰਚ ਨੂੰ ਨੋਟ ਕਰੋ: ਪੈਚਿੰਗ, ਅਪਡੇਟ, ਸਮਰੱਥਾ ਯੋਜ਼ਨਾ, ਅਤੇ ਘਟਨਾ ਪ੍ਰਤਿਕਿਰਿਆ।

ਕਦਮ 9: ਫੈਸਲਿਆਂ, ਵਿਕਲਪਾਂ, ਅਤੇ ਵਾਪਸੀਯੋਗਤਾ ਨੂੰ ਕੈਪਚਰ ਕਰੋ

ਅਲੰਡੇ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ‘ਹੋ ਜਾਂਦੇ’—ਉਹ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਚੋਣਾਂ ਦੇ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਚੋਣਾਂ ਸਿਰਫ਼ ਚੈਟ ਲੌਗ ਜਾਂ ਕਿਸੇ ਦੀ ਯਾਦ ਵਿੱਚ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਟੀਮ ਮੁੜ-ਚਰਚਾ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਸਮਰਥ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜਦ ਲੋੜ ਬਦਲਦੀ ਹੈ ਤਾਂ ਸੰਘਰਸ਼ ਹੁੰਦਾ ਹੈ।

ADRs ਨਾਲ ਫੈਸਲੇ searchable ਬਣਾਓ

ਹਰ ਮੁੱਖ ਚੋਣ ਲਈ ਇੱਕ Architecture Decision Record (ADR) ਬਣਾਓ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਇੱਕਸਾਰ ਰੱਖੋ:

• Context: ਤੁਸੀਂ ਕਿਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਪਾਬੰਦੀਆਂ
• Decision: ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ
• Alternatives considered: 2–3 ਯੋਗ ਵਿਕਲਪ
• Why: ਤਾਂਕੀ ਤੁਸੀਂ ਇਸਦੀ ਸਥਾਪਨਾ ਅਤੇ ਟਰੇਡ-ਆਫ਼ ਦੱਸ ਸਕੋ
• Consequences: ਇਹ ਕੀ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕੀ ਸੀਮਿਤ ਕਰਦਾ ਹੈ

AI ਇੱਥੇ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਕਾਰੀ ਹੈ: ਇਹ ਚਰਚਾਵਾਂ ਤੋਂ ਵਿਕਲਪਾਂ ਦਾ ਸੰਖੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਟਰੇਡ-ਆਫ਼ ਨਿਕਾਲ ਸਕਦਾ ਹੈ, ਅਤੇ ADRs ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਫਿਰ ਸਹੀ ਕਰ ਸਕਦੇ ਹੋ।

ਡਿਜ਼ਾਈਨ ਵਿੱਚ "exit ramps" ਬਣਾਓ

ਅਨੁਮਾਨ ਬਦਲਦੇ ਹਨ: ਟ੍ਰੈਫਿਕ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਸਕਦਾ ਹੈ, ਕੰਪਲਾਇੰਸ ਕਸੇ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਇਕਸਾ API ਅਣਭਰੋਸੇਯੋਗ ਹੋ ਸਕਦੀ ਹੈ। ਹਰ ਮੁੱਖ ਅਨੁਮਾਨ ਲਈ ਇੱਕ exit ramp ਜੋੜੋ:

• “ਜੇ ਅਸੀਂ X requests/sec ਤੋਂ ਉੱਤੇ ਚਲੇ ਜਾਈਏ ਤਾਂ single DB ਤੋਂ read replicas ਵੱਲ ਜਾਵੋ।”
• “ਜੇ ਵੇਂਡਰ API SLA Y ਤੋਂ ਹੇਠਾਂ ਆ ਜਾਂਦੀ ਹੈ ਤਾਂ queue + retry worker ਸ਼ੁਰੂ ਕਰੋ।”

ਇਸ ਨਾਲ ਭਵਿੱਖ ਦਾ ਬਦਲਾਅ ਇੱਕ ਯੋਜਿਤ ਚਲਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ, ਹਲਕਾ ਅੱਗੇ ਦਾ ਅਗਿਆਨ-ਸੰਘਰਸ਼ ਨਹੀਂ।

ਜੋਖ਼ਮ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਪ੍ਰੂਫ਼ ਪੌਇੰਟ ਅਤੇ ਵਰਜ਼ਨ ਕਰੋ

ਖਤਰਨਾਕ ਚੋਣਾਂ ਦੇ ਨਾਲ ਪਰਖਯੋਗ ਮਾਈਲਸਟੋਨ ਜੋੜੋ: ਸਪਾਈਕਸ, ਬੈਂਚਮਾਰਕ, ਛੋਟੇ ਪ੍ਰੋਟੋਟਾਈਪ, ਜਾਂ ਲੋਡ ਟੈਸਟ। ਉਮੀਦ ਕੀਤੇ ਨਤੀਜੇ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਸੰਲਗਨ ਕਰੋ।

ਅੰਤ ਵਿੱਚ, ਜਿਵੇਂ ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ ADRs ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ। ਇਤਿਹਾਸ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰੋ—ਅਪਡੇਟ ਜੁੜਾਉ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਕੀ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ ਬਦਲਿਆ। ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਹਲਕਾ ਢਾਂਚਾ ਚਾਹੀਦਾ ਹੋਵੇ, ਇੱਕ ਆਧਾਰਤ ਟੈਂਪਲੇਟ /blog/adr-template ਵਰਗੀ ਸਥਾਨਕ ਲਿੰਕ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ।

ਕਦਮ 10: ਸਮੀਖਿਆ ਅਤੇ ਸਬੂਤ ਨਾਲ ਆਰਕੀਟੈਕਚਰ ਵੈਲਿਡੇਟ ਕਰੋ

ਇੱਕ ਡਰਾਫਟ ਆਰਕੀਟੈਕਚਰ "ਖੂਬਸੂਰਤ" ਲਗਣ 'ਤੇ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਉਸ ਵੇਲੇ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦ ਉਹ ਲੋਕ ਜਿਹੜੇ ਇਹ ਬਣਾਉਣ, ਸੁਰੱਖਿਅਤ ਕਰਨ, ਚਲਾਉਣ, ਅਤੇ ਭੁਗਤਾਨ ਕਰਨਗੇ ਇਹ ਮੰਨ ਲੈਂ ਕਿ ਇਹ ਕੰਮ ਕਰੇਗਾ—ਅਤੇ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਮੁਸ਼ਕਲ ਹਿੱਸਿਆਂ ਲਈ ਸਬੂਤ ਹੋਣ।

ਕੇਂਦਰਿਤ ਆਰਕੀਟੈਕਚਰ ਸਮੀਖਿਆ ਚਲਾਓ

ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਵਰਤੋ ਤਾਂ ਕਿ ਅਹਿਮ ਸਵਾਲ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਾਹਮਣੇ ਆਉਣ:

• ਸੁਰੱਖਿਆ: authentication/authorization ਮਾਡਲ, secrets ਹੁੰਡਾਉਣ, least privilege, ਆਡਿਟ ਲੌਗ
• ਪ੍ਰਾਈਵੇਸੀ: ਡੇਟਾ ਕਲਾਸੀਫਿਕੇਸ਼ਨ, retention, ਪਹੁੰਚ ਕੰਟਰੋਲ, PII ਫਲੋ ਮੈਪਿੰਗ, deletion ਬੇਨਤੀਆਂ
• ਫੇਲ ਮੋਡਸ: ਡਿਗਰੇਡਡ ਵਿਵਹਾਰ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਬੈਕਆਫ, ਆਈਡੈਮਪੋਟੈਂਸੀ, dead-letter queues, rate limits
• ਓਪਰੇਸ਼ਨਲ ਰੇਡੀਨੈੱਸ: ਮਾਨੀਟਰਿੰਗ, ਅਲਰਟਿੰਗ, ਰਨਬੁਕਸ, ਓਨ-ਕਾਲ ਮਾਲਕੀਅਤ, ਬੈਕਅੱਪ/ਰੀਸਟੋਰ

ਆਉਟਪੁੱਟ ਸਪੱਸ਼ਟ ਰੱਖੋ: “ਅਸੀਂ ਕੀ ਕਰਾਂਗੇ?” ਅਤੇ “ਕੌਣ ਇਸਦਾ ਮਾਲਕ ਹੈ?”—ਸਧਾਰਨ ਨਿਯਤੀਆਂ ਜਾਂ ਮਨੋਰਥਕ ਇरਾਦਿਆਂ ਨਹੀਂ।

ਅੰਕਾਂ ਨਾਲ ਵੈਲਿਡੇਟ ਕਰੋ (ਰੇਂਜਜ਼, ਦਾਹੀ ਨਹੀਂ)

ਇੱਕ ਹੀ throughput ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ, ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ ਲੋਡ ਅਤੇ ਲਾਗਤ ਰੇਂਜ ਬਣਾਓ:

• ਟ੍ਰੈਫਿਕ: P50 / P95 requests per second (ਉਦਾਹਰਣ: 50–200 RPS ਮਿਆਦਾ, 500–1,000 RPS ਚੁੱਟੀ)
• ਸਟੋਰੇਜ ਵਰਧਨ: ਮਹੀਨਾਵਾਰ ਰੇਂਜ ਨਾਲ retention ਅਨੁਮਾਨ
• ਲਾਗਤ ਚਾਲਕ: ਮਾਡਲ/API ਉਪਯੋਗ, ਕਮਪਿਊਟ autoscaling, ਡੇਟਾ egress, ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ

AI ਨੂੰ ਆਪਣੀ ਗਣਿਤ ਅਤੇ ਅਨੁਮਾਨ ਦਿਖਾਉਣ ਲਈ ਕਹੋ, ਫਿਰ ਮੌਜੂਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਜਾਂ ਤੁਲਨਾਤਮਕ ਸਿਸਟਮਾਂ ਨਾਲ ਸੰਨਦੀ ਦੀ ਜਾਂਚ ਕਰੋ।

ਡਿਪੈਂਡੈਂਸੀ ਅਤੇ ਵੇਂਡਰ ਜੋਖ਼ਮ ਮੁਲਾਂਕਣ

ਤੱਤੀਆ ਡਿਪੈਂਡੈਂਸੀ (LLM provider, vector DB, queue, auth service) ਦੀ ਸੂਚੀ ਬਣਾਓ। ਹਰ ਇੱਕ ਲਈ ਲਿਖੋ:

• ਜੇ ਇਹ ਉਪਲਬਧ ਨਾ ਰਹੇ ਤਾਂ ਕੀ ਟੁਟੇਗਾ?
• ਪ੍ਰੋਵਾਇਡਰ ਬਦਲਣਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੈ?
• ਕੀ ਕੋਈ ਠੇਕਾ, ਖੇਤਰ, ਜਾਂ ਕੰਪਲਾਇੰਸ ਸੀਮਾਵਾਂ ਹਨ?

ਮਨੁੱਖੀ ਸਾਈਨ-ਆਫ਼ ਨੁਕਤੇ ਪਰिभਾਸ਼ਿਤ ਕਰੋ

ਸਮੀਖਿਆਆਂ ਸਪੱਸ਼ਟ ਬਣਾਓ, ਨਾ ਕਿ ਇੱਛਾ-ਸਨਕਲਪ:

• Product: ਯੂਜ਼ਰ ਫਲੋਜ਼, SLA, ਿਸਕੋਪ ਬਾਰਡਰਸ
• Security/Privacy: ਧਮਕੀ ਮਾਡਲ ਨਤੀਜੇ, ਡੇਟਾ ਹੈਂਡਲਿੰਗ ਮਨਜ਼ੂਰੀ
• Ops/SRE: ਨਿਰੀਖਣਯੋਗਤਾ ਯੋਜਨਾ, ਘਟਨਾ ਪ੍ਰਤਿਕਿਰਿਆ, ਸਮਰੱਥਾ ਅਨੁਮਾਨ
• Engineering: ਇੰਟਰਫੇਸ, ਮਾਈਲਸਟੋਨ, ਮਾਈਗਰੇਸ਼ਨ ਯੋਜਨਾ

ਜਦੋਂ ਅਸਹਿਮਤੀਆਂ ਬਚਿ ਜਾਂਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਫੈਸਲੇ-ਲੈਣ ਵਾਲੇ ਆਈਟਮਾਂ ਵਜੋਂ ਦਰਜ ਕਰੋ ਜਿਸ ਲਈ ਮਾਲਕ ਅਤੇ ਤਾਰੀਖ ਹੋਵੇ—ਫਿਰ ਸਪਸ਼ਟਤਾ ਨਾਲ ਅੱਗੇ ਵਧੋ।

AI ਨਾਲ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਹਿਯੋਗ ਕਰਨ ਦੇ ਤਰੀਕੇ

AI ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਜ਼ਾਈਨ ਸਾਥੀ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਜੂਨੀਅਰ ਆਰਕੀਟੈਕਟ ਵਾਂਗ ਵਰਤੋਂ: ਤੇਜ਼ ਵਿਕਲਪ ਬਣਾਉਂਦਾ, ਪਰ ਸਪੱਸ਼ਟ ਸੰਦਰਭ, ਚੈੱਕ ਅਤੇ ਦਿਸ਼ਾ ਦੀ ਲੋੜ।

AI ਨੂੰ ਅਸਾਈਨ ਕਰਨ ਵਾਲੇ ਪ੍ਰਾਂਪਟ ਜਿਹੜੇ ਅਨੁਮਾਨ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ

AI ਨੂੰ ਇੱਕ "ਬਾਕਸ" ਦਿਓ ਜਿਸ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਹੈ: ਬਿਜ਼ਨਸ ਲਕਸ਼, ਉਪਭੋਗਤਾ, ਸਕੇਲ, ਬਜਟ, ਡੈਡਲਾਈਨ, ਅਤੇ ਕੋਈ ਨਾਨ-ਨੇਗੋਸ਼ੀਏਬਲ (ਟੈਕ ਸਟੈਕ, ਕੰਪਲਾਇੰਸ, ਹੋਸਟਿੰਗ)। ਫਿਰ ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਪਹਿਲਾਂ ਅਨੁਮਾਨ ਅਤੇ ਖੁੱਲੇ ਸਵਾਲ ਲਿਖੇ ਜਾਣ।

ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕੋਈ ਪਾਬੰਦੀ ਮਾਇਨੇ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ—ਮਾਡਲ ਤੋਂ ਇਸਨੂੰ ਅਨੁਮਾਨ ਕਰਨ ਦੀ ਉਮੀਦ ਨਾ ਰੱਖੋ।

ਕਿੱਥੇ "vibe-coding" ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ

ਜੇ ਤੁਹਾਡਾ ਲਕਸ਼ ਆਰਕੀਟੈਕਚਰ ਯੋਜਨਾ ਤੋਂ ਕੰਮ ਕਰ ਰਹੇ ਸਿਸਟਮ ਤੱਕ ਜਲਦੀ ਜਾਣਾ ਹੈ ਬਿਨਾ ਫੈਸਲਿਆਂ ਨੂੰ ਹੈਂਡਆਫ਼ 'ਚ ਖੋਣ ਦੇ, ਤਾਂ ਵਰਕਫਲੋ ਟੂਲ ਮਹੱਤਵਪੂਰਨ ਹੈ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇੱਥੇ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹੀ ਚੈਟ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ, ਉही constraints ਨੂੰ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਤੱਕ ਲਿਜਾ ਸਕਦੀ ਹੈ: planning mode, ਦੁਹਰਾਓਯੋਗ iterations, ਅਤੇ ਜਦ ਤੁਸੀਂ pipeline ਦੀ ਮਲਕੀਅਤ ਲੈਣ ਲਈ ਤਯਾਰ ਹੋਵੋਗੇ ਤਾਂ ਸੋర్స్ ਕੋਡ ਇੱਕਸਪੋਰਟ ਕਰਨ ਦੀ ਸਮਰੱਥਾ।

ਇਸ ਨਾਲ ਆਰਕੀਟੈਕਚਰ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਘੱਟ ਨਹੀਂ ਹੁੰਦੀ—ਜੇ ਕਿਛ, ਇਹ ਅਨੁਮਾਨ ਅਤੇ ਗੈਰ-ਕਾਰਜਕ ਲੋੜਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ਿਤ ਕਰਨ ਦੀ ਮਿਆਦ ਵੱਧਾ ਦਿੰਦਾ ਹੈ—ਕਿਉਂਕਿ ਤੁਸੀਂ ਪ੍ਰਸਤਾਵ ਤੋਂ ਚਲ ਰਹੀ ਐਪ ਤੱਕ ਜਲਦੀ ਜਾ ਸਕਦੇ ਹੋ।

ਮੁੜ-ਵਰਤੋਂਯੋਗ ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ

ਛੋਟੇ ਟੈਮਪਲੇਟ ਵਰਤੋ ਜੋ ਸੰਰਚਿਤ ਆਊਟਪੁੱਟ ਦੇਂਦੇ ਹਨ:

You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)

(ਤਿੰਨ-ਬਿੰਦੂਆਂ ਵਾਲਾ ਕੋਡ ਬਲਾਕ ਯਥਾਵਤ ਛੱਡਿਆ ਗਿਆ ਹੈ—ਇਸ ਨੂੰ ਤਬਦੀਲ ਨਾ ਕਰੋ।)

"ਤਨਿਖ" ਅਤੇ ਸੁਧਾਰ" ਲੂਪ ਨਾਲ ਇਟਰੇਟ ਕਰੋ

ਪਹਿਲੀ ਪਾਸ ਲਈ ਪੁੱਛੋ, ਫਿਰ ਤੁਰੰਤ ਇਕ ਟੀਕਾ-ਟਿੱਪਣੀ ਮੰਗੋ:

• "ਇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਕਿਹੜੀ ਚੀਜ਼ ਨਾਜੁਕ ਜਾਂ ਜੋਖ਼ਮ ਭਰੀ ਹੈ?"
• "ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਅਜੇ ਤੱਕ ਪੂਰੀ ਨਹੀਂ ਹੋਈਆਂ?"
• "ਜੇ ਅਸੀਂ ਅੱਧਾ ਸਮਾਂ ਹੁੰਦਾ ਤਾਂ ਤੁਹਾਡਾ ਕੀ ਸਧਾਰਨ ਤਰੀਕਾ ਹੁੰਦਾ?"

ਇਸ ਨਾਲ ਮਾਡਲ ਇੱਕ ਮਾਤਰ ਰਾਹ 'ਤੇ ਜਲਦੀ ਨਹੀਂ ਟਿੱਕਦਾ।

ਆਮ ਫੇਲ ਮੋਡ ਲਈ ਧਿਆਨ ਰੱਖੋ

AI ਭਰੋਸੇਯੋਗ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਆਮ ਮੁੱਦੇ:

• ਹਲੂਸੀਨੇਟ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ/ਫੀਚਰ—ਪੁਸ਼ਟੀ ਜਾਂ ਸਪੱਸ਼ਟ ਅਣਸਥਿਤੀ ਜ਼ਰੂਰੀ ਹੈ
• ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਪਾਬੰਦੀਆਂ (ਲਾਗਤ, ਡੇਟਾ ਰਿਹਾਇਸ਼, ਟੀਮ ਹੁਨਰ)—ਹਰ ਡਿਜ਼ਾਈਨ ਚੋਣ ਨੂੰ ਲੋੜ ਨਾਲ ਜੋੜਨ ਲਈ ਕਹੋ
• ਓਵਰ-ਇੰਜੀਨੀਅਰਿੰਗ—"ਛੋਟੀ ਤੋਂ ਯੋਗ" ਸਮਾਰਟ ਵਿਕਲਪ ਮੰਗੋ

ਤੁਸੀਂ ਚਾਹੋ ਤਾਂ ਆਉਟਪੁੱਟ ਨੂੰ ਹਲਕਾ ADRs ਵਜੋਂ ਕੈਪਚਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਰੇਪੋ ਦੇ ਨਾਲ ਰੱਖ ਸਕਦੇ ਹੋ (ਵੇਖੋ /blog/architecture-decision-records).

ਛੋਟਾ ਵਾਕ-ਪ੍ਰਦਰਸ਼ਨ: ਧੁੰਦਲੇ ਪ੍ਰਾਂਪਟ ਤੋਂ ਤਿਆਰ-ਬਣਾਉਣ ਯੋਜਨਾ ਤੱਕ

ਧੁੰਦਲਾ ਪ੍ਰਾਂਪਟ: “ਇੱਕ ਸਿਸਟਮ ਬਣਾਓ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਦੱਸੇ ਜੇ ਡਿਲਿਵਰੀ ਦੇਰੀ ਹੋਏਗੀ।”

1) ਇਸਨੂੰ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲੋ

AI ਇਸਨੂੰ ਨਿਮਨ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ:

• ਉਪਭੋਗਤਾ: operations ਟੀਮ, ਅੰਤਿਮ ਗਾਹਕ
• ਮੁੱਖ ਫਲੋ: shipment status ingest → delay risk detect → notify → outcomes track
• ਗੈਰ-ਕਾਰਜਕ: status change ਤੋਂ 2 ਮਿੰਟ ਦੇ ਅੰਦਰ alerts, 99.9% availability, ਵਿਵਾਦਾਂ ਲਈ ਆਡਿਟ ਟ੍ਰੇਲ

2) ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲ ਦੇਣ ਵਾਲੇ ਅਨੁਮਾਨ

ਦੋ ਸ਼ੁਰੂਆਤੀ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਉਲਟ ਸਕਦੇ ਹਨ:

• ਅਨੁਮਾਨ A: status updates carriers ਤੋਂ real time (webhooks) ਆ ਰਹੇ ਹਨ। ਜੇ ਇਹ ਸੱਚ ਹੈ, ਤਾਂ event-driven processing ਫਿੱਟ ਹੁੰਦੀ ਹੈ।
• ਅਨੁਮਾਨ B: updates ਹਰ 15 ਮਿੰਟ 'ਤੇ poll ਹੋ ਰਹੇ ਹਨ। ਜੇ ਇਹ ਸੱਚ ਹੈ, ਤਾਂ scheduling, rate-limit handling ਦੀ ਲੋੜ ਹੈ, ਅਤੇ 2 ਮਿੰਟ alert SLA ਮੁਮਕਿਨ ਨਹੀਂ ਹੋ ਸਕਦੀ ਬਿਨਾਂ input ਨੀਂਦਰ ਨੂੰ ਫੇਰ ਕਰਨ ਦੇ।

ਇਹਨਾਂ ਨੂੰ ਲਿਖਣ ਨਾਲ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਗਲਤ ਚੀਜ਼ ਤਿਆਰ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹੋ।

3) ਵਿਕਲਪ → ਟਰੇਡ-ਆਫ਼ ਫੈਸਲਾ

AI candidate architectures ਸੁਝਾਉਂਦਾ ਹੈ:

• Option 1: Synchronous API: carrier webhook → delay scoring service → notification service

  • Pros: ਸਧਾਰਨ, ਘੱਟ ਹਿੱਸੇ
  • Cons: webhook timeouts lost updates ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ; ਸਪਾਈਕ ਸਕੋਰਿੰਗ ਨੂੰ ਓਵਰਲੋਡ ਕਰ ਸਕਦੇ ਹਨ

• Option 2: Queue-based: webhook → enqueue event → workers score delays → notifications

  • Pros: bursts ਨੂੰ ਬਫ਼ਰ ਕਰਦਾ ਹੈ, retries ਸੁਰੱਖਿਅਤ, ਬਿਹਤਰ ਨਿਰੀਖਣਯੋਗਤਾ
  • Cons: ਹੋਰ ਕੰਪੋਨੈਂਟ, eventual consistency

ਟਰੇਡ-ਆਫ਼ ਫੈਸਲਾ: ਜੇ carrier reliability ਅਤੇ ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ ਜੋਖ਼ਮ ਹਨ ਤਾਂ queue-based ਚੁਣੋ; ਜੇ ਵੋਲਿਊਮ ਘੱਟ ਅਤੇ carrier SLA ਮਜ਼ਬੂਤ ਹੈ ਤਾਂ synchronous ਚੁਣੋ।

4) ਅੰਤਿਮ ਯੋਜਨਾ ਅਤੇ ਡਿਲਿਵਰੇਬਲ

ਬਣਾਉਣਯੋਗ ਬਣਾਉਣ ਲਈ ਡਿਲਿਵਰੇਬਲ:

• ਸੰਦਰਭ ਅਤੇ ਕ੍ਰਮ ਰਿਖੇ ਡਾਇਗ੍ਰਾਮ
• ਡੇਟਾ ਮਾਡਲ + ਇਵੈਂਟ ਸਕੀਮਾ
• Queue vs synchronous ਚੋਣ ਨੂੰ ਦਰਸਾਉਂਦੇ ADRs
• ਰਨਬੁਕਸ (ਫੇਲ ਮੋਡ, retries, on-call checks)
• ਬੈਕਲੌਗ epics (carrier integration, scoring rules, notification templates, monitoring)