തടസ്സങ്ങളില്ലാതെ വളരുന്ന ഒരു സിസ്റ്റമാണ് ഓരോ എഞ്ചിനീയറിംഗ് ടീമിനും വേണ്ടത്. ട്രാഫിക് സുഗമമായി വർദ്ധിക്കുന്നതും സെർവറുകൾ തടസ്സമില്ലാതെ പ്രവർത്തിക്കുന്നതും നമ്മൾ സങ്കൽപ്പിക്കുന്നു.

ബുദ്ധിമുട്ടുകളില്ലാതെ വളരാൻ കഴിയുന്ന ഒരു സിസ്റ്റമാണ് എല്ലാ എഞ്ചിനീയറിംഗ് ടീമുകളും ആഗ്രഹിക്കുന്നത്. ട്രാഫിക് സുഗമമായി വർദ്ധിക്കുന്നതും, സെർവറുകൾ കൃത്യമായി പ്രവർത്തിക്കുന്നതും, വരുമാനം ഉയർന്നു വരുന്നതും നമ്മൾ സങ്കൽപ്പിക്കുന്നു. എന്നാൽ യാഥാർത്ഥ്യം മുന്നിൽ വന്നുനിൽക്കുമ്പോൾ അവസ്ഥ മാറുന്നു. ഒരു വൈറൽ മാർക്കറ്റിംഗ് ക്യാമ്പയിൻ വലിയൊരു കൂട്ടം ഉപയോക്താക്കളെ എത്തിക്കുമ്പോൾ ഡാറ്റാബേസ് ലോക്ക് ആകുന്നു, മൂന്ന് മണിക്ക് ആരോ പരിഭ്രാന്തനായി സർവീസുകൾ റീസ്റ്റാർട്ട് ചെയ്യുന്നു. ഇതിന് കാരണം ഉപയോഗിക്കുന്ന ടൂളുകളാണെന്ന് നമ്മൾ വിചാരിക്കുന്നു. കൂടുതൽ കോറുകൾ (cores), വേഗതയേറിയ ഡിസ്കുകൾ, അല്ലെങ്കിൽ മറ്റൊരു കാഷിംഗ് ലെയർ (caching layer) എന്നിവ ആവശ്യമായിരുന്നു എന്ന് നമ്മൾ സ്വയം പറഞ്ഞുതരുന്നു. എന്നാൽ വളർച്ച എന്നത് ഹാർഡ്‌വെയറിൽ നിന്നല്ല വരുന്നത്. അത് ഘടനയിൽ (structure) നിന്നാണ് വരുന്നത്. നിങ്ങളുടെ അടിത്തറയ്ക്ക് ഭാരം വിതരണം ചെയ്യാൻ കഴിയില്ലെങ്കിൽ, ഓരോ പുതിയ ഉപയോക്താവും ഒരു വിജയത്തിന് പകരം ഒരു ബാധ്യതയായി മാറും.

തകർന്ന അടിത്തറയെ ഉപകരണങ്ങൾ കൊണ്ട് രക്ഷിക്കാനാവില്ല

നിങ്ങൾക്ക് നൂറുകണക്കിന് cloud instances പ്രവർത്തിപ്പിക്കാം, വിവിധ ഭൂമിശാസ്ത്രപരമായ പ്രദേശങ്ങൾക്കിടയിൽ load balancers ചേർക്കാം, കൂടാതെ ഒരു ഗ്ലോബൽ content delivery network ഉപയോഗിച്ച് എല്ലാ സ്റ്റാറ്റിക് അസറ്റുകളും (static assets) കാഷ് (cache) ചെയ്യാം. ഇവയെല്ലാം പ്രവർത്തനക്ഷമത വർദ്ധിപ്പിക്കാൻ സഹായിക്കുന്നവയാണ്. എന്നിരുന്നാലും, പൂജ്യത്തെ എത്ര ഗുണിച്ചാലും പൂജ്യം തന്നെ ലഭിക്കും. സങ്കീർണ്ണമായ ഡിപെൻഡൻസികളുള്ള (dependencies) ഒരു monolithic application, അതിന്റെ അടിത്തറയിൽ എത്ര വലിയ ഹാർഡ്‌വെയർ ഉണ്ടെങ്കിലും അതിന്റെ തന്നെ ഭാരം കൊണ്ട് തകർന്നടിയും.

പ്രൊഡക്റ്റ് കാറ്റലോഗ് (product catalog), പേയ്‌മെന്റ് പ്രോസസ്സിംഗ്, യൂസർ ഓതന്റിക്കേഷൻ എന്നിവയെല്ലാം ഒരൊറ്റ കോഡ്ബേസിൽ (codebase) പ്രവർത്തിക്കുന്ന ഒരു ഓൺലൈൻ സ്റ്റോർ സങ്കൽപ്പിക്കുക. ചെക്കൗട്ട് പ്രക്രിയ (checkout flow) സാവധാനത്തിലാകുമ്പോൾ, സൈറ്റ് മുഴുവൻ മന്ദഗതിയിലാകുന്നു. ലോഗിൻ പേജ് തടസ്സപ്പെടുന്നു. ബ്രൗസിംഗ് അനുഭവം മോശമാകുന്നു. ഒരു ഭാഗത്തെ തടസ്സം (bottleneck) പരിഹരിക്കാൻ മറ്റെല്ലാ ഭാഗങ്ങളും ഒപ്പം മാറ്റേണ്ടി വരുന്നു. ഇത് ചിലവേറിയതും കാര്യക്ഷമമല്ലാത്തതും ദുർബലവുമാണ്. പേജുകൾ ഉടൻ ലോഡ് ആകേണ്ടതിന് ഉപയോക്താക്കൾ കാത്തുനിൽക്കുമ്പോൾ, ആർക്കും പ്രയോജനമില്ലാത്ത കമ്പ്യൂട്ട് പവറിനായി നിങ്ങൾ പണം ചെലവഴിക്കേണ്ടി വരുന്നു.

ആർക്കിടെക്ചർ (Architecture) ആണ് ഈ കെണിയിൽ നിന്നുള്ള പരിഹാരം. നിങ്ങളുടെ ഉപകരണങ്ങൾ സഹായിക്കണോ അതോ ദോഷം ചെയ്യണോ എന്ന് തീരുമാനിക്കുന്നത് ഈ അദൃശ്യമായ അസ്ഥികൂടമാണ്.

ഒരു മികച്ച ആർക്കിടെക്ചർ എന്നാൽ യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കുന്നത്?

ഉത്തരവാദിത്തങ്ങൾ എവിടെയായിരിക്കണം എന്നതിനായുള്ള ഒരു പ്ലാൻ മാത്രമാണ് മികച്ച ആർക്കിടെക്ചർ. അത് തുടക്കത്തിലേ പ്രയാസകരമായ ചോദ്യങ്ങൾ ചോദിക്കുന്നു. ഒരു ഭാഗം തകർന്നാൽ എന്ത് സംഭവിക്കും? റെക്കമെൻഡേഷൻ എഞ്ചിനെ (recommendation engine) ബാധിക്കാതെ തന്നെ ബില്ലിംഗ് ലോജിക് മാറ്റാൻ നിങ്ങൾക്ക് കഴിയുമോ? നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഒരു ഭാഗത്ത് ട്രാഫിക് വർദ്ധിച്ചാൽ അത് സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളെ ബാധിക്കാതെ സാധാരണ നിലയിൽ പ്രവർത്തിക്കാൻ കഴിയുമോ? നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പ്രോഗ്രാമിംഗ് ലാംഗ്വേജ്, ഫ്രെയിംവർക്ക് അല്ലെങ്കിൽ ക്ലൗഡ് പ്രൊവൈഡർ എന്നിവയേക്കാൾ വളരെ പ്രധാനമാണ് ഈ ചോദ്യങ്ങൾ.

നല്ല ആർക്കിടെക്ചർ നിങ്ങൾക്ക് മാറ്റങ്ങൾ വരുത്താനുള്ള സ്വാതന്ത്ര്യം നൽകുന്നു. ഒരു ടീമിന്റെ പരീക്ഷണങ്ങൾ മറ്റൊരു ടീമിന്റെ പ്രൊഡക്ഷൻ വർക്ക് ലോഡിനെ (production workload) തകിടം മറിക്കാത്ത രീതിയിൽ വ്യക്തമായ അതിർവരമ്പുകൾ അത് നിശ്ചയിക്കുന്നു. പരാജയങ്ങളെ ഒരു അപ്രതീക്ഷിത സംഭവമായി കാണുന്നതിന് പകരം, പ്രവർത്തനത്തിന്റെ സ്വാഭാവികമായ ഒരു അവസ്ഥയായി അത് കണക്കാക്കുന്നു. പരാജയങ്ങളെ മുൻകൂട്ടി കണ്ട് നിങ്ങൾ രൂപകൽപ്പന ചെയ്യുമ്പോൾ, നിങ്ങൾ ചില്ല് വീടുകൾ പണിയുന്നത് നിർത്തി, വളയാൻ ശേഷിയുള്ള ഘടനകൾ പണിയാൻ തുടങ്ങുന്നു.

പ്രായോഗികമായ ഒരു രീതിയായി മൈക്രോസർവീസസ് (Microservices)

അത്തരം ഒരു ഘടന കൈവരിക്കാനുള്ള പ്രായോഗികമായ ഒരു മാർഗ്ഗമാണ് നിങ്ങളുടെ ആപ്ലിക്കേഷനെ microservices ആയി വിഭജിക്കുക എന്നത്. ഒരു വലിയ കോഡ്ബേസിന് പകരം, ആപ്പിനെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കുന്നു. ഓരോ ഭാഗവും ഒരു പ്രത്യേക ജോലി ചെയ്യുന്നു. പേയ്‌മെന്റ് സർവീസ് ഇടപാടുകൾ കൈകാര്യം ചെയ്യുന്നു. ഇൻവെന്ററി സർവീസ് സ്റ്റോക്ക് പരിശോധിക്കുന്നു. നോട്ടിഫിക്കേഷൻ സർവീസ് ഇമെയിലുകളും ടെക്സ്റ്റ് സന്ദേശങ്ങളും അയക്കുന്നു. അവ നേരിട്ടുള്ള മെമ്മറി ആക്സസ് വഴിയോ പങ്കിട്ട ഡാറ്റാബേസ് ടേബിളുകൾ വഴിയോ അല്ല, മറിച്ച് നിർവചിക്കപ്പെട്ട ഇന്റർഫേസുകൾ (interfaces) വഴിയാണ് ആശയവിനിമയം നടത്തുന്നത്.

ഈ വേർതിരിവ് സാങ്കേതികമായും സംഘടനാപരമായും പ്രവർത്തിക്കാൻ കൂടുതൽ അവസരം നൽകുന്നു.

മുഴുവൻ സിസ്റ്റത്തെയും തകരാതെ ചെറിയ ഭാഗങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യാം

സർവീസുകൾ ചെറുതും കൃത്യമായ ലക്ഷ്യങ്ങളുള്ളതുമാണെങ്കിൽ, മുഴുവൻ സിസ്റ്റത്തെയും ബാധിക്കാതെ ഒരു ഭാഗം മാത്രം പരിഷ്കരിക്കാൻ (patch) സാധിക്കും. ഷിപ്പിംഗ് കാൽക്കുലേഷൻ അൽഗോരിതത്തിൽ ഒരു ബഗ് (bug) നിങ്ങളുടെ ടീം കണ്ടെത്തിയാൽ, ആ സർവീസ് മാത്രം ശരിയാക്കി വിന്യസിക്കാം. ബാക്കി ആപ്ലിക്കേഷൻ പ്രവർത്തിച്ചുകൊണ്ടേയിരിക്കും. ഉപയോക്താക്കൾക്ക് ഇപ്പോഴും ഉൽപ്പന്നങ്ങൾ കാണാനും, ലോഗിൻ ചെയ്യാനും, കാർട്ടിലേക്ക് സാധനങ്ങൾ ചേർക്കാനും സാധിക്കും. ഒരു ചെറിയ മാറ്റം പോലും വലിയ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കില്ല. എന്നാൽ ഒരു monolith സിസ്റ്റത്തിൽ, ഒരു ചെറിയ പിശക് പോലും ചെക്കൗട്ട്, രജിസ്ട്രേഷൻ, റിപ്പോർട്ടിംഗ് എന്നിവയെല്ലാം ഒരേസമയം തകരാൻ കാരണമായേക്കാം.

ട്രാഫിക് കൂടുമ്പോൾ പ്രത്യേക ഫംഗ്ഷനുകൾ മാത്രം സ്കെയിൽ ചെയ്യാം

ഒരു ആപ്ലിക്കേഷനിലെ ട്രാഫിക് എല്ലായിടത്തും ഒരുപോലെയല്ല. ഒരു ഫ്ലാഷ് സെയിൽ (flash sale) സമയത്ത്, നിങ്ങളുടെ ഓർഡർ പൈപ്പ്‌ലൈൻ സമ്മർദ്ദത്തിലായേക്കാം, എന്നാൽ കണ്ടന്റ് മാനേജ്‌മെന്റ് സിസ്റ്റം ഒട്ടും ഉപയോഗിക്കപ്പെടാതെ ഇരിക്കാം. ഒരു ടൈറ്റ്ലി കപ്പിൾഡ് (tightly coupled) സിസ്റ്റത്തിൽ, നിങ്ങൾക്ക് എല്ലാം കൂടി സ്കെയിൽ ചെയ്യേണ്ടി വരും അല്ലെങ്കിൽ ഒന്നും ചെയ്യാനാവില്ല. എന്നാൽ microservices ഉപയോഗിക്കുമ്പോൾ, നിങ്ങൾക്ക് കൃത്യമായി വിഭവങ്ങൾ (resources) ഉപയോഗിക്കാം. ചെക്കൗട്ട് സർവീസിന്റെ കൂടുതൽ ഇൻസ്റ്റൻസുകൾ പ്രവർത്തിപ്പിക്കുക. പ്രൊഡക്റ്റ് കാറ്റലോഗ് അതിന്റെ സാധാരണ രീതിയിൽ തന്നെ പ്രവർത്തിക്കട്ടെ. ഒരു ഉൽപ്പന്നം ലോഞ്ച് ചെയ്യുമ്പോൾ, ഇമേജ് പ്രോസസ്സിംഗ് വർക്കർമാർക്ക് ആയിരക്കണക്കിന് തംബ്‌നെയിലുകൾ പ്രോസസ്സ് ചെയ്യേണ്ടി വന്നേക്കാം, അതേസമയം സെർച്ച് ഇൻഡക്സ് ശാന്തമായിരിക്കാം. ഇമേജ് വർക്കർമാരുടെ ആവശ്യത്തിന് വേണ്ടി മാത്രം സെർച്ച് ക്ലസ്റ്റർ വികസിപ്പിക്കേണ്ട കാര്യമില്ല. ഉപയോക്താക്കൾക്ക് ആവശ്യമുള്ള ഇടങ്ങളിൽ മാത്രം നിങ്ങൾ പണം ചെലവഴിക്കുന്നു, അങ്ങനെ സമ്മർദ്ദഘട്ടത്തിലും നിങ്ങളുടെ സിസ്റ്റം വേഗത്തിൽ പ്രവർത്തിക്കുന്നു.

ദീർഘനേരത്തെ ഡൗൺടൈം (Downtime) ഇല്ലാതെ പുതിയ കോഡ് വിന്യസിക്കാം

ചെറിയ സർവീസുകൾ ഉപയോഗിക്കുന്നതിലൂടെ മെയിന്റനൻസ് വിൻഡോകളുടെ (maintenance windows) ആവശ്യം ഇല്ലാതാക്കുന്ന രീതിയിലുള്ള ഡിപ്ലോയ്‌മെന്റ് പാറ്റേണുകൾ സാധ്യമാകും. നിങ്ങൾക്ക് റോളിംഗ് ഡിപ്ലോയ്‌മെന്റുകൾ (rolling deployments) ഉപയോഗിക്കാം; അതായത്, ബാക്കിയുള്ളവ ട്രാഫിക് കൈകാര്യം ചെയ്തുകൊണ്ടിരിക്കുമ്പോൾ പുതിയ കോഡ് ഇൻസ്റ്റൻസുകളുടെ ഒരു ചെറിയ ഭാഗത്തേക്ക് മാത്രം എത്തിക്കാം. നിങ്ങളുടെ എറർ റേറ്റുകൾ (error rates) ശ്രദ്ധിക്കുക, എന്തെങ്കിലും പിശക് തോന്നിയാൽ സെക്കൻഡുകൾക്കുള്ളിൽ റിക്വസ്റ്റുകൾ പഴയ വേർഷനിലേക്ക് തിരിച്ചുവിടാം. ബ്ലൂ-ഗ്രീൻ ഡിപ്ലോയ്‌മെന്റുകൾ (blue-green deployments) വഴി നിങ്ങൾക്ക് തികച്ചും പുതിയൊരു എൻവയോൺമെന്റ് സജ്ജീകരിക്കാനും അത് പരിശോധിച്ച ശേഷം വളരെ കുറഞ്ഞ റിസ്കിൽ ട്രാഫിക് അതിലേക്ക് മാറ്റാനും സാധിക്കും. ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾ (database migrations) ഒരാൾ നേരിട്ട് ചെയ്യുന്നതിനായി മണിക്കൂറുകളോളം സിസ്റ്റം ഓഫാക്കേണ്ടി വരില്ല.

പുതിയ ഫീച്ചറുകൾ വേഗത്തിൽ നിർമ്മിക്കാം

വലിയ കോഡ്ബേസുകൾ (codebases) ജാഗ്രത ആവശ്യപ്പെടുന്നു. ഒരു ചെറിയ മാറ്റത്തിന് പോലും ബന്ധമില്ലാത്ത ആയിരക്കണക്കിന് വരികളായുള്ള ലോജിക് മനസ്സിലാക്കേണ്ടി വരും, മണിക്കൂറുകൾ എടുക്കുന്ന റീഗ്രഷൻ ടെസ്റ്റുകൾ (regression tests) ആവശ്യമായി വരും, കൂടാതെ റോക്കറ്റ് വിക്ഷേപണം പോലെ തോന്നിപ്പിക്കുന്ന ഡിപ്ലോയ്‌മെന്റ് ഷെഡ്യൂളുകളും ഉണ്ടാകും. ചെറിയ സർവീസുകൾ ഈ ഭയം ഇല്ലാതാക്കുന്നു. ഒരു ടീമിന് തങ്ങൾ നന്നായി അറിയുന്ന ഒരു സർവീസിലെ ഏതാനും നൂറ് വരികൾ മാറ്റുന്നതിലൂടെ പുതിയൊരു ഫീച്ചർ നിർമ്മിക്കാൻ കഴിയും. അവർ ഒരേ ദിവസം തന്നെ അത് കമിറ്റ് ചെയ്യാനും ടെസ്റ്റ് ചെയ്യാനും ഷിപ്പ് ചെയ്യാനും സാധിക്കും. ഈ വേഗത വർദ്ധിച്ചുകൊണ്ടേയിരിക്കും. സർവീസുകൾ വ്യക്തമായ ഉത്തരവാദിത്തങ്ങളാൽ പരിമിതപ്പെടുമ്പോൾ, ടീമുകൾ പരസ്പരം തടസ്സപ്പെടുന്നത് ഒഴിവാക്കുന്നു. അവർക്ക് അവരുടെ ഡൊമെയ്‌നിൽ പൂർണ്ണമായ നിയന്ത്രണമുണ്ടാകും.

സ്വയംപര്യാപ്തത വലിയ തടസ്സങ്ങൾ ഒഴിവാക്കുന്നു

ഓരോ സർവീസും സ്വന്തമായി പ്രവർത്തിക്കുന്നു. ഈ സ്വയംപര്യാപ്തത കേവലം ഒരു സംഘടനാ സൗകര്യം മാത്രമല്ല; അത് ഒരു ഘടനാപരമായ ഇൻഷുറൻസ് കൂടിയാണ്. റിക്കമെൻഡേഷൻ എഞ്ചിൻ (recommendation engine) പ്രവർത്തനരഹിതമായാലും സ്റ്റോറിൽ ഉൽപ്പന്നങ്ങൾ വിൽക്കാൻ സാധിക്കണം. അനലിറ്റിക്സ് പൈപ്പ്‌ലൈനിൽ (analytics pipeline) എന്തെങ്കിലും പിശക് സംഭവിച്ചാലും ലോഗിൻ സർവീസിന് ഉപയോക്താക്കളെ ഓതന്റിക്കേറ്റ് ചെയ്യാൻ സാധിക്കണം. ഒരു പരാജയം മുഴുവൻ സിസ്റ്റത്തെയും ബാധിക്കാതിരിക്കാൻ നിങ്ങൾ സർവീസുകൾക്കിടയിൽ സർക്യൂട്ട് ബ്രേക്കറുകളും (circuit breakers) ഫാൾബാക്ക് പാത്തുകളും (fallback paths) രൂപകൽപ്പന ചെയ്യുന്നു. സിസ്റ്റം തകരാതെ തന്നെ ഉപയോക്താക്കളുടെ എണ്ണത്തിനനുസരിച്ച് വളരാൻ അതിന് സാധിക്കുന്നു.

ഒരു മുന്നറിയിപ്പ്: അന്ധമായി വിഭജിക്കരുത്

ഇതിനർത്ഥം ആദ്യ ദിവസം തന്നെ നിങ്ങളുടെ കോഡ്ബേസ് വിഭജിക്കണം എന്നല്ല. മൈക്രോസർവീസുകൾക്ക് വ്യക്തമായ അതിർവരമ്പുകൾ ആവശ്യമാണ്. ഒരു ഡൊമെയ്ൻ എവിടെ അവസാനിക്കുന്നുവെന്നും മറ്റൊന്ന് എവിടെ തുടങ്ങുന്നുവെന്നും നിങ്ങളുടെ ടീമുകൾക്ക് അറിയില്ലെങ്കിൽ, അവർ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റത്തിന് പകരം ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് മെസ്സ് (distributed mess) ആണ് സൃഷ്ടിക്കുക. നിങ്ങൾ കോഡിന്റെ സങ്കീർണ്ണതയ്ക്ക് പകരം ഓപ്പറേഷണൽ സങ്കീർണ്ണത (operational complexity) നേരിടേണ്ടി വരും; പെട്ടെന്ന് തന്നെ നെറ്റ്‌വർക്ക് ലേറ്റൻസി (network latency), ഡിസ്ട്രിബ്യൂട്ടഡ് ട്രാൻസാക്ഷനുകൾ (distributed transactions), റീട്രൈ സ്റ്റോംസ് (retry storms), ഡസൻ കണക്കിന് ലോഗ് സ്ട്രീമുകളിലൂടെയുള്ള ഒബ്സർവബിലിറ്റി (observability) എന്നിവ കൈകാര്യം ചെയ്യേണ്ടി വരും. ഒരു സ്ലോ ചെക്കൗട്ട് (slow checkout) ഡിബഗ് ചെയ്യുക എന്നത് നാല് നെറ്റ്‌വർക്ക് ഹോപ്പുകളിലൂടെയും മൂന്ന് വ്യത്യസ്ത ഡാറ്റാ സ്റ്റോറുകളിലൂടെയും ഒരു റിക്വസ്റ്റിനെ പിന്തുടരുക എന്നതിനർത്ഥമാകും.

നിങ്ങളുടെ ടീം ഇതിന് തയ്യാറല്ലെങ്കിൽ, ചികിത്സയേക്കാൾ കഠിനമായിരിക്കും ആ പ്രശ്നം. ചിലപ്പോൾ ഒരു മോഡുലാർ മോണോലിത്ത് (modular monolith) ഉപയോഗിച്ച് തുടങ്ങുന്നതാണ് ബുദ്ധിപരമായ നീക്കം. പേയ്‌മെന്റ് ലോജിക് ഇൻവെന്ററി ലോജിക്കിൽ നിന്ന് കോഡ്ബേസിനുള്ളിൽ തന്നെ വേർതിരിച്ചു വെക്കുക, അവ ഒരേസമയം ഡിപ്ലോയ് ചെയ്താലും കുഴപ്പമില്ല. ഇന്റേണൽ എപിഐകൾ (internal APIs), ഒരേ എൻജിനുള്ളിലെ തന്നെ പ്രത്യേക ഡാറ്റാബേസ് സ്കീമകൾ (database schemas) എന്നിവ ഉപയോഗിച്ച് അതിർവരമ്പുകൾ ഉറപ്പാക്കുക. ആ വിഭജനങ്ങൾ സുസ്ഥിരമാണെന്ന് ബോധ്യപ്പെടുമ്പോഴും ട്രാഫിക് പാറ്റേണുകൾ അതിന് അനുയോജ്യമാണെന്ന് കാണുമ്പോഴും ഒരു സർവീസ് വേർതിരിച്ചെടുക്കുക. ആർക്കിടെക്ചർ എന്നത് ഒരു ബ്ലോഗ് പോസ്റ്റ് വായിച്ചതുകൊണ്ട് ഒറ്റരാത്രികൊണ്ട് പണിത മതിലുകളല്ല, മറിച്ച് ബോധപൂർവ്വമായ തീരുമാനങ്ങളിലൂടെ നിർമ്മിച്ച വാതിലുകളായിരിക്കണം.

വ്യക്തമായ ലക്ഷ്യത്തോടെ തുടങ്ങുക

ശക്തമായ ആർക്കിടെക്ചർ എന്നത് അഞ്ച് വർഷത്തിന് ശേഷമുള്ള ട്രാഫിക് പ്രവചിക്കുന്നതിനെക്കുറിച്ചല്ല. അത് നിങ്ങൾക്ക് കൂടുതൽ ഓപ്ഷനുകൾ നൽകുന്നതിനെക്കുറിച്ചാണ്. വെബ് ആപ്പ് വളർത്താൻ നിങ്ങൾക്ക് ടൂളുകളെ മാത്രം ആശ്രയിക്കാൻ കഴിയില്ല, എന്നാൽ സമ്മർദ്ദം കൂടുന്നതിന് മുമ്പ് പ്രശ്നങ്ങളിൽ നിന്ന് പുറത്തുകടക്കാൻ നിങ്ങൾക്ക് ചിന്തിക്കാൻ കഴിയും. ഉത്തരവാദിത്തങ്ങൾ തമ്മിലുള്ള അതിർവരമ്പുകളെ ബഹുമാനിക്കുക. സ്വന്തം നിയന്ത്രണമുള്ള ചെറിയ, ശ്രദ്ധ കേന്ദ്രീകരിച്ച ഭാഗങ്ങൾ നിർമ്മിക്കുക. മുഴുവൻ സിസ്റ്റത്തെയും തകരാതെ വേഗത്തിൽ നീങ്ങാൻ ടീമുകൾക്ക് സ്വയംഭരണം (autonomy) നൽകുക. നിങ്ങൾ ഒരു ശക്തമായ ആർക്കിടെക്ചറോടെ തുടങ്ങുമ്പോൾ, പിന്നീട് സമയം ലാഭിക്കാൻ സാധിക്കും; കാരണം സൈറ്റ് തകർച്ചയുടെ വക്കിലായിരിക്കുമ്പോൾ നിങ്ങൾക്ക് കോർ ലോജിക് വീണ്ടും എഴുതേണ്ടി വരില്ല.

യഥാർത്ഥ പാഠം

സ്കെയിലബിലിറ്റി (Scalability) എന്നത് വളർച്ച വരുമ്പോൾ മാത്രം ചേർക്കുന്ന ഒരു ഫീച്ചറല്ല. അത് നിങ്ങളുടെ സിസ്റ്റത്തിലൂടെ ഉത്തരവാദിത്തങ്ങൾ എങ്ങനെ ഒഴുകണം എന്നതിനെക്കുറിച്ച് നിങ്ങൾ നേരത്തെ എടുത്ത തീരുമാനങ്ങളുടെ സ്വാഭാവിക ഫലമാണ്. ശരിയായ വിഭജനങ്ങൾ തിരഞ്ഞെടുക്കുക. പരാജയങ്ങൾ ഒറ്റപ്പെടുത്തുക. പ്രശ്നമുണ്ടാകുന്ന ഭാഗങ്ങൾ സ്കെയിൽ ചെയ്യുക, ശരിയായി പ്രവർത്തിക്കുന്നവയെ മാറ്റമില്ലാതെ നിലനിർത്തുക. അങ്ങനെ ചെയ്താൽ, പിന്നീട് നിങ്ങൾ ചേർക്കുന്ന ടൂളുകൾക്ക് ശക്തമായ ഒരു അടിത്തറയിൽ പ്രവർത്തിക്കാൻ സാധിക്കും.