நான் ஒரு "Set It and Forget It" Sync முறையை எவ்வாறு உருவாக்கினேன்

தயாரிப்பு விலைகள் பல இடங்களில் மாறுகின்றன. அவை admin panel, bulk imports அல்லது API webhooks மூலம் மாறலாம்.

இந்த மாற்றங்களை ஒரு வெளிப்புற சந்தைக்கு (external marketplace) sync செய்ய விரும்பினால், நீங்கள் ஒரு சிக்கலை எதிர்கொள்வீர்கள். ஒவ்வொரு code path-லும் ஒரு sync call-ஐச் சேர்ப்பது ஒரு தவறு. நீங்கள் ஒன்றை மறந்துவிடலாம் அல்லது ஒன்றைச் சிதைத்துவிடலாம். பராமரிப்பு (Maintenance) ஒரு பயங்கரமான விஷயமாக மாறிவிடும்.

Django signals இதைத் தீர்க்கின்றன. நீங்கள் model save event-உடன் இணைக்கலாம் (hook). இது ஒவ்வொரு மாற்றத்தையும் ஒரே இடத்தில் கண்டறியும்.

ஆனால் signals-ல் ஒரு குறைபாடு உள்ளது. நீங்கள் ஒரே நேரத்தில் 100 விலைகளை மாற்றினால், signal 100 முறை இயங்கும். இது 100 API calls-களைத் தூண்டும். இதனால் நீங்கள் rate limits-ஐத் தாண்டிவிடலாம் அல்லது வளங்களை (resources) வீணடிக்கலாம்.

இதைச் சரிசெய்ய நான் மூன்று பகுதிகளைக் கொண்ட ஒரு முறையைப் (pattern) பயன்படுத்துகிறேன்:

• உடனடியாகச் செயல்படுவதற்குப் பதிலாக, ID-களைச் சேகரிக்கும் ஒரு signal handler. • நகல்களை (duplicates) நீக்க ஒரு per-thread set. • அனைத்தையும் ஒரே நேரத்தில் செயல்படுத்த transaction.on_commit பயன்படுத்தும் ஒரு flush callback.

இது எவ்வாறு செயல்படுகிறது என்பது இதோ:

  1. threading.local() பயன்படுத்துங்கள் Global variable-ஐப் பயன்படுத்த வேண்டாம். Global variables கோரிக்கைகளுக்கு (requests) இடையே நிலையைப் (state) பகிர்ந்து கொள்கின்றன. இது தரவு கசிவுக்கு (data leakage) வழிவகுக்கும். threading.local() தரவை ஒரு தனி thread-க்கு மட்டும் தனிமைப்படுத்துகிறது.

  2. பதிவு செய்யுங்கள், செயல்படாதீர்கள் Signal handler தயாரிப்பு ID-யை ஒரு set-ல் சேர்க்கிறது. தரவுத்தளப் பரிவர்த்தனை (database transaction) வெற்றிகரமாக முடிந்த பின்னரே ஒரு flush function-ஐ இயக்க Django-விடம் அது கூறுகிறது. இது சேமிக்கத் தவறிய தரவை sync செய்வதைத் தடுக்கிறது.

  3. வேலையைத் தொகுக்கவும் (Batch the work) Transaction commit ஆகும்போது, flush function இயங்கும். அது set-ஐ நகலெடுத்து (copy), அதைத் துடைத்துவிடும் (clear). பின்னர் அந்த முழு ID பட்டியலையும் ஒரு service layer-க்கு அனுப்பும்.

Service layer அனைத்துத் தயாரிப்புகளையும் எடுக்க ஒரு bulk query-யைச் செய்யும். அது அவற்றைச் கடை (store) வாரியாகத் தொகுக்கும். இறுதியாக, ஒவ்வொரு கடைக்கும் Celery-க்கு ஒரு தனி பணியை (task) அனுப்பும்.

இதன் நன்மைகள் தெளிவாக உள்ளன:

நீங்கள் ஒருமுறை அமைப்பை உருவாக்கிவிட்டால் போதும். நீங்கள் பின்னர் சேர்க்கும் ஒவ்வொரு புதிய அம்சமும் இந்த sync முறையுடன் தானாகவே இணைந்து செயல்படும்.

Django-வில் வெளிப்புற API sync-களை நீங்கள் எவ்வாறு கையாளுகிறீர்கள்? நீங்கள் signals பயன்படுத்துகிறீர்களா அல்லது வேறு முறையைப் பயன்படுத்துகிறீர்களா?

ஆதாரம்: https://dev.to/acel/how-i-built-a-set-it-and-forget-it-sync-system-with-django-signals-2ld7