શું તમારું Scalable Backend એક Ticking Time Bomb છે?
ઘણા ડેવલપર્સ માને છે કે Scaling એટલે વધુ સર્વર્સ ઉમેરવા. તેઓ વધુ યુઝર્સને હેન્ડલ કરવા માટે Cloud-native ટૂલ્સ અને Distributed databases નો ઉપયોગ કરે છે. પરંતુ આ ઘણીવાર એક નવી સમસ્યા ઊભી કરે છે. તમે કોઈ કિલ્લો નથી બનાવી રહ્યા, તમે પત્તાનો મહેલ (house of cards) બનાવી રહ્યા છો.
કોઈપણ પ્લાન વગર Scaling horizontally કરવાથી માત્ર તમારા Failure domains વધે છે. જો તમારી સિસ્ટમમાં Fault tolerance નો અભાવ હોય, તો એક નાની ભૂલ બધું જ ક્રેશ કરી શકે છે.
સાચી સિસ્ટમ બનાવવા માટે તમારે બે ક્ષેત્રો પર ધ્યાન કેન્દ્રિત કરવું જોઈએ:
- Fault Tolerance વધુ instances ઉમેરવાથી correlated failures અટકતા નથી. તમારે failures ને isolate કરવા જોઈએ જેથી તે ફેલાય નહીં.
- Multiple Availability Zones નો ઉપયોગ કરો.
- બે મોટા instances ના બદલે નાના service instances નો ઉપયોગ કરો.
- Raft અથવા Paxos જેવા quorum-based consensus નો ઉપયોગ કરો. આ split-brain scenarios ને અટકાવે છે જ્યાં બે regions પોતાને leader માને છે.
- Network split દરમિયાન faulty regions ને બંધ કરવા માટે fencing mechanisms નો ઉપયોગ કરો.
- Data Consistency Eventual consistency ઝડપ માટે ઉત્તમ છે. પરંતુ તે ક્રિટિકલ બિઝનેસ લોજિક માટે ખરાબ છે. Payments અથવા Account balances માટે, તમારે Strong consistency ની જરૂર છે.
- એવી Distributed transactions પર આધાર રાખશો નહીં જે તમારી સિસ્ટમને ધીમી પાડે છે.
- Transactional Outbox Pattern નો ઉપયોગ કરો.
- તમારા મુખ્ય ડેટા અને એક "outbox" task ને એક જ transaction માં તમારા local database માં લખો.
- તે tasks ને message queue માં મોકલવા માટે એક relayer નો ઉપયોગ કરો.
- ખાતરી કરો કે તમારી downstream services idempotent છે જેથી તેઓ duplicate messages ને સુરક્ષિત રીતે હેન્ડલ કરી શકે.
સાચી Scalability એ Resilience વિશે છે. જો તમે આ principles ની અવગણના કરશો, તો તમે માત્ર નિષ્ફળતાઓ માટે મોટું મેદાન બનાવી રહ્યા છો. આજે જ Worst-case scenario માટે ડિઝાઇન કરો.
Source: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7