உங்கள் Scalable Backend ஒரு வெடிக்கக் காத்திருக்கும் கால வெடிகுண்டா?
பல டெவலப்பர்கள் scaling என்பது அதிக சர்வர்களைச் சேர்ப்பது என்று நினைக்கிறார்கள். அதிக பயனர்களைக் கையாள அவர்கள் cloud-native கருவிகள் மற்றும் distributed databases-களைப் பயன்படுத்துகிறார்கள். ஆனால் இது பெரும்பாலும் ஒரு புதிய சிக்கலை உருவாக்குகிறது. நீங்கள் ஒரு கோட்டையை உருவாக்கவில்லை; நீங்கள் ஒரு சீட்டுக்கட்டுக் கோபுரத்தை (house of cards) உருவாக்குகிறீர்கள்.
முறையான திட்டம் இல்லாமல் horizontally scale செய்வது உங்கள் failure domains-களை விரிவுபடுத்துகிறது. உங்கள் அமைப்பில் fault tolerance இல்லையென்றால், ஒரு சிறிய பிழை கூட அனைத்தையும் முடக்கிவிடும்.
ஒரு உண்மையான அமைப்பை உருவாக்க நீங்கள் இரண்டு விஷயங்களில் கவனம் செலுத்த வேண்டும்:
- Fault Tolerance அதிக instances-களைச் சேர்ப்பது தொடர்புடைய தோல்விகளைத் (correlated failures) தடுக்காது. தோல்விகள் பரவாமல் இருக்க அவற்றை நீங்கள் தனிமைப்படுத்த வேண்டும்.
- பல Availability Zones-களைப் பயன்படுத்தவும்.
- இரண்டு பெரிய instances-களைப் பயன்படுத்துவதற்குப் பதிலாக, பல சிறிய service instances-களைப் பரவியாகப் பயன்படுத்தவும்.
- Raft அல்லது Paxos போன்ற quorum-based consensus முறைகளைப் பயன்படுத்தவும். இது இரண்டு பிராந்தியங்கள் (regions) தங்களைத் தாங்களே தலைவன் என்று நினைக்கும் split-brain சூழல்களைத் தவிர்க்கும்.
- நெட்வொர்க் பிளவு (network split) ஏற்படும் போது, பழுதான பிராந்தியங்களை முடக்குவதற்கு fencing mechanisms-களைப் பயன்படுத்தவும்.
- Data Consistency Eventual consistency வேகத்திற்குச் சிறந்தது. ஆனால் முக்கியமான வணிகத் தர்க்கங்களுக்கு (business logic) இது மிகவும் மோசமானது. பணம் செலுத்துதல் அல்லது கணக்கு இருப்புகளைப் (account balances) பொறுத்தவரை, உங்களுக்கு strong consistency தேவை.
- உங்கள் அமைப்பைக் کندமாக்கும் distributed transactions-களைச் சார்ந்திருக்க வேண்டாம்.
- Transactional Outbox Pattern-ஐப் பயன்படுத்தவும்.
- உங்கள் முதன்மைத் தரவையும் (main data) மற்றும் ஒரு "outbox" பணியையும் ஒரே ஒரு transaction மூலம் உங்கள் local database-இல் எழுதவும்.
- அந்தப் பணிகளை ஒரு message queue-க்கு அனுப்ப ஒரு relayer-ஐப் பயன்படுத்தவும்.
- உங்கள் downstream services 'idempotent'-ஆக இருப்பதை உறுதி செய்யவும், அப்போதுதான் அவை நகல் செய்திகளை (duplicate messages) பாதுகாப்பாகக் கையாள முடியும்.
உண்மையான scalability என்பது மீள்திறனைப் (resilience) பற்றியது. இந்தத் தத்துவங்களைப் புறக்கணித்தால், நீங்கள் தோல்விகளுக்கான ஒரு பெரிய விளையாட்டு மைதானத்தை மட்டுமே உருவாக்குகிறீர்கள். இன்றைய தினமே மோசமான சூழலுக்கும் (worst-case scenario) ஏற்றவாறு வடிவமைக்கவும்.
ஆதாரம்: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7