సైన్‌అప్ ఈమెయిల్స్ పరిష్కరించబడిన సమస్యలలా అనిపిస్తాయి. ఒక యూజర్ ఫారమ్‌ను సబ్మిట్ చేస్తారు, మీ యాప్ ఒక జాబ్‌ను క్యూలో ఉంచుతుంది, ఒక ప్రొవైడర్ సందేశాన్ని డెలివరీ చేస్తాడు, మరియు అకౌంట్ యాక్టివేట్ అవుతుంది. కానీ నిజంగా రికార్డ్ చేయబడే డేటాను మీరు పరిశీలిస్తే, ఆ చిత్రం చాలా గందరగోళంగా కనిపిస్తుంది. ప్రారంభ అభ్యర్థన (initial request) మరియు తుది డెలివరీ నిర్ధారణ మధ్య ఎక్కడో, టీమ్‌లు అనుకోకుండా ఒక ఆర్కైవ్‌ను నిర్మించే అవకాశం ఉంది. రిక్వెస్ట్ లాగ్స్ పూర్తి పేలోడ్‌లను (payloads) క్యాప్చర్ చేస్తాయి. వెబ్‌హుక్ హ్యాండ్లర్లు మొత్తం JSON బాడీలను పర్సిస్టెంట్ స్టోరేజీలోకి పంపిస్తారు. సపోర్ట్ ఏజెంట్లు సబ్జెక్ట్ లైన్‌లు మరియు స్నిప్పెట్‌లను టికెట్లలో పేస్ట్ చేస్తారు. QA ఎన్విరాన్‌మెంట్లు రెండర్ చేయబడిన ఈమెయిల్స్ యొక్క స్క్రీన్‌షాట్‌లను సేకరిస్తాయి, ఇవి నెలల తరబడి షేర్డ్ ఫోల్డర్‌లలో ఉండిపోతాయి. ఇలా కొన్ని సైకిల్స్ తర్వాత, ఏది పంపబడింది, ఏది చదవబడింది మరియు మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఇంకా ఏముంది అనే విషయంలో ఏ సిస్టమ్ వద్ద నిజమైన సమాచారం ఉందో టీమ్‌లోని ఎవరూ ఖచ్చితంగా చెప్పలేరు.

ఇది ముఖ్యమైన విషయం ఎందుకంటే ప్రైవసీ కంప్లయన్స్ (privacy compliance) అనేది కేవలం ఒక అబ్‌స్ట్రాక్ట్ లీగల్ ఎక్సర్‌సైజ్ మాత్రమే కాదు. ఇది ఒక ప్రాక్టికల్ ఇంజనీరింగ్ డిసిప్లిన్. మీ సైన్‌అప్ ఈమెయిల్ పైప్‌లైన్‌ను మీరు సమీక్షించినప్పుడు, మీ టీమ్‌ను ఒక ప్రశ్న అడగండి: రేపు ఒక యూజర్ మీకు ఈమెయిల్ చేసి, వారి సైన్‌అప్ ఫ్లో గురించి మీరు ఏ డేటాను ఉంచుకున్నారో ఖచ్చితంగా అడిగితే, మీరు త్వరగా సమాధానం చెప్పగలరా మరియు సరైన వాటిని ఖచ్చితంగా తొలగించగలరా? ఒకవేళ నిజాయితీతో కూడిన సమాధానం "బహుశా" అని వస్తే, మీ పైప్‌లైన్‌ను శుభ్రం చేయాల్సిన అవసరం ఉంది. అస్పష్టమైన నమ్మకం అంటే సాధారణంగా డేటా లాగింగ్ ప్లాట్‌ఫారమ్‌లు, హెల్ప్‌డెస్క్‌లు, స్టేజింగ్ ఇన్‌బాక్స్‌లు మరియు లోకల్ డెవలపర్ మెషీన్‌లలో చెల్లాచెదురుగా ఉందని అర్థం.

షాడో రికార్డులు ఎలా పెరుగుతాయి

డీబగ్గింగ్ టూల్స్ డిజైన్ ప్రకారం కాకుండా అనుకోకుండా విస్తరిస్తుంటాయి. ఒక ఇంజనీర్ థర్డ్-పార్టీ ప్రొవైడర్‌తో డెలివరీ స్పైక్‌ను డయాగ్నోస్ చేయడానికి వెర్బోస్ లాగింగ్‌ను (verbose logging) డిప్లాయ్ చేస్తారు. ఫిక్స్ పూర్తవుతుంది, కానీ లాగ్ లెవల్ ఎప్పుడూ తగ్గదు. నెలల తర్వాత, ప్రతి ఈమెయిల్ డిస్పాచ్ ఇప్పటికీ పూర్తి రిసిపియంట్ అడ్రస్‌లు మరియు మెసేజ్ బాడీలను పన్నెండు నెలల రిటెన్షన్ డిఫాల్ట్‌తో ఉన్న సెంట్రలైజ్డ్ ప్లాట్‌ఫారమ్‌కు రాస్తుంది. ఈలోగా, సపోర్ట్ లీడ్ కొత్త ఉద్యోగులకు ఈమెయిల్ కంటెంట్‌ను టికెట్‌లో కాపీ చేయమని శిక్షణ ఇస్తారు, తద్వారా కాంటెక్స్ట్ "చూడటం సులభంగా" ఉంటుంది. డిజైనర్లు టెంప్లేట్‌లను వెరిఫై చేయడానికి క్యాచ్-ఆల్ ఇన్‌బాక్స్‌తో కాన్ఫిగర్ చేయబడిన స్టేజింగ్ ఎన్విరాన్‌మెంట్, లోడ్ టెస్ట్ సమయంలో ఎవరైనా ప్రొడక్షన్ వంటి డేటాను దాని వైపు పంపడం వల్ల వేలాది మంది నిజమైన యూజర్ ఈమెయిల్ అడ్రస్‌లను సేకరిస్తుంది. విడివిడిగా చూస్తే ఈ నిర్ణయాలన్నీ చిన్నవిగా అనిపించవచ్చు. కానీ ఇవన్నీ కలిసి మీ ప్రైమరీ అప్లికేషన్ డేటాబేస్ వెలుపల ఉండే యూజర్ యాక్టివిటీ యొక్క షాడో రికార్డ్‌ను సృష్టిస్తాయి.

ఆ షాడో రికార్డ్ కేవలం కంప్లయన్స్ సమస్య మాత్రమే కాదు. అది ఒక సెక్యూరిటీ లయబిలిటీ (security liability). 2025లో సగటు గ్లోబల్ బ్రీచ్ ఖర్చు $4.44 మిలియన్లకు చేరుకుందని IBM నివేదించింది. పరిధి పెరిగే కొద్దీ ఖర్చు కూడా పెరుగుతుంది. ఒక అటాకర్ అవసరానికి మించి ఎక్కువ డేటాను కలిగి ఉన్న సిస్టమ్‌లోకి ప్రవేశించినప్పుడు, వారు మరింత డేటాను దొంగిలిస్తారు. మీ సైన్‌అప్ లాగ్స్‌లో పూర్తి మెసేజ్ కంటెంట్, వెరిఫికేషన్ లింక్‌లు మరియు పర్సనల్ ఐడెంటిఫైయర్‌లు ఉంటే, మీ లాగింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్ బ్రీచ్ కావడం అనేది మీ ప్రొడక్షన్ డేటాబేస్ బ్రీచ్ అయినంత తీవ్రంగా మారుతుంది. సరైన రిటెన్షన్ లిమిట్‌లు కేవలం ఆడిటర్లను సంతృప్తి పరచడమే కాదు; ఏదైనా తప్పు జరిగినప్పుడు నష్ట పరిధిని (blast radius) కూడా తగ్గిస్తాయి.

ఒక సరళమైన డీబగ్గింగ్ నియమం

ఏది ఉంచాలి మరియు ఏది తొలగించాలి అని నిర్ణయించేటప్పుడు నేను ఒక సరళమైన ఫిల్టర్‌ను ఉపయోగిస్తాను: డెలివరీ సమస్యలను డీబగ్ చేయడానికి తగినంత డేటాను ఉంచండి, కానీ యూజర్ యొక్క మెసేజ్ హిస్టరీని తిరిగి సృష్టించడానికి తగినంత డేటాను ఉంచకండి. ఒక ఈమెయిల్ క్యూ చేయబడింది, పంపబడింది మరియు అక్నాలెడ్జ్ చేయబడింది అని తెలుసుకోవడానికి మరియు సబ్జెక్ట్ లైన్ ఏమిటి లేదా వెరిఫికేషన్ టోకెన్ ఏమిటి అని ఖచ్చితంగా తెలుసుకోవడానికి మధ్య నిజమైన తేడా ఉంది. ఆపరేషనల్ డేటా (Operational data) మీరు ఒక మార్గాన్ని ట్రాస్ చేయడంలో సహాయపడుతుంది. కంటెంట్ డేటా (Content data) మీరు ఎవరిదో మెయిల్ చదవడానికి అనుమతిస్తుంది. మీ ఇన్‌ఫ్రాస్ట్రక్చర్ మొదటి దానికే ప్రాధాన్యత ఇవ్వాలి మరియు రెండవ దానిని దూకుడుగా తొలగించాలి.

ఏమి ఉంచాలి మరియు ఏమి తొలగించాలి

ఆ నియమం ఆచరణలో ఎలా ఉంటుందో ఇక్కడ ఉంది.

ఉంచండి:

  • Internal operation IDs. మీ API నుండి మీ జాబ్ క్యూ ద్వారా, ప్రొవైడర్‌కు మరియు వెబ్‌హుక్ ద్వారా తిరిగి వచ్చే ఈమెయిల్ కోసం ఒక స్థిరమైన ఐడెంటిఫైయర్.
  • User or account IDs. ప్రతి సబ్‌సిస్టమ్‌లో ఈమెయిల్ అడ్రస్‌ను నిల్వ చేయకుండా, ఈవెంట్‌ను ఒక ప్రొఫైల్‌తో అనుసంధానించడానికి సరిపడా సమాచారం.
  • Delivery states. queued, sent, delivered, bounced, లేదా failed వంటి సాధారణ స్టేటస్ స్ట్రింగ్స్.
  • Provider message IDs. మీ ఈమెయిల్ సర్వీస్ తిరిగి ఇచ్చే రిఫరెన్స్ స్ట్రింగ్. ప్రొవైడర్‌తో డెలివరీ క్లెయిమ్‌ల గురించి వాదించడానికి ఇది చాలా కీలకం.
  • Short retention windows for error metadata. ఒక జాబ్ విఫలమైనప్పుడు, మీకు కొన్ని రోజుల స్టాక్ ట్రేస్‌లు లేదా రిక్వెస్ట్ డంప్‌లు అవసరం కావచ్చు. వాటిని సంవత్సరాల తరబడి కాకుండా, రోజుల్లో ఆటో-డిలీట్ అయ్యేలా సెట్ చేయండి.

తప్పించుకోండి:

  • దీర్ఘకాలిక లాగ్స్‌లో పూర్తి మెసేజ్ బాడీలను నిల్వ చేయడం. ఈమెయిల్ యొక్క టెక్స్ట్ లేదా HTML అనేది రెండర్-టైమ్ సిస్టమ్స్‌లో లేదా తాత్కాలిక టెస్టింగ్ ఎన్విరాన్‌మెంట్లలో ఉండాలి, మీ శాశ్వత లాగ్ స్టోర్‌లో కాదు.
  • షేర్డ్ డ్యాష్‌బోర్డ్‌లలో ముడి వెరిఫికేషన్ లింక్‌లు. వెరిఫికేషన్ URL అనేది తాత్కాలిక పాస్‌వర్డ్ లాగా పనిచేస్తుంది. దానిని ఒక క్రెడెన్షియల్‌గా పరిగణించండి. దానిని పంపే విధానం (dispatch mechanism) తప్ప మరెక్కడా దానిని బహిర్గతం చేయకండి.
  • ప్రధాన సాక్ష్యంగా స్క్రీన్‌షాట్‌లను ఉపయోగించడం. QA కి విజువల్ కన్ఫర్మేషన్ కావాలంటే, ఆటోమేటెడ్ రెండర్ టెస్ట్‌లు లేదా నిర్ణీత సమయం తర్వాత ఆటోమేటిక్‌గా తొలగించబడే తాత్కాలిక ఇన్‌బాక్స్‌లను ఉపయోగించండి. PNG ఫైల్‌లు మీ ఆడిట్ ట్రైల్‌గా మారనివ్వకండి.
  • యజమాని లేని అడ్ హాక్ ఎగుమతులు (exports). సపోర్ట్ లేదా ఆప్స్ టీమ్ ఇటీవలి సైన్-అప్ ఈమెయిల్స్ యొక్క CSV ఫైల్‌ను ఎగుమతి చేస్తే, ఆ ఫైల్ ఇప్పుడు ఎవరో ఒకరి ల్యాప్‌టాప్‌లో ఉంటుంది. అది మళ్ళీ దొరికే వరకు ఎవరూ దాని గురించి పట్టించుకోరు.

సాక్ష్యాన్ని మూడు పొరలుగా విభజించండి

ఒక ఆరోగ్యకరమైన ఆర్కిటెక్చర్, సున్నితమైన సమాచారానికి తక్కువ కాలపరిమితిని కలిగి ఉండేలా, ఈమెయిల్ సాక్ష్యాలను మూడు వేర్వేరు పొరలుగా (layers) విభజిస్తుంది. మీ application database పంపాలనే ఉద్దేశాన్ని రికార్డ్ చేస్తుంది: యూజర్ ID, టెంప్లేట్ పేరు, టైమ్‌స్టాంప్ మరియు ఆపరేషన్ ID. మీ worker telemetry ప్రయత్నాన్ని రికార్డ్ చేస్తుంది: ప్రొవైడర్ API రెస్పాన్స్, మెసేజ్ ID, HTTP స్టేటస్ మరియు రీట్రై కౌంట్. మీ staging or preview environment ఈమెయిల్ సరిగ్గా ఉందో లేదో నిరూపిస్తుంది: రెండర్ టెస్ట్‌లు లేదా నిర్ణీత కాలం (బహుశా ఏడు రోజులు) తర్వాత ఆటోమేటిక్‌గా డిలీట్ అయ్యే తాత్కాలిక ఇన్‌బాక్స్‌లు. ప్రతి పొర ఒక వేర్వేరు ప్రశ్నకు సమాధానం ఇస్తుంది. వాటిలో ఏదీ మరొక దాని పూర్తి కంటెంట్‌ను డూప్లికేట్ చేయాల్సిన అవసరం లేదు.

ఈ విభజన ఆటోమేషన్‌ను సులభతరం చేస్తుంది. మీ సపోర్ట్ టీమ్‌కు అవసరమైన ఆపరేషనల్ సాక్ష్యాలను మీరు తొలగిస్తారనే ఆందోళన లేకుండా, మీరు రిటెన్షన్ పాలసీలను (retention policies) అమలు చేయవచ్చు. డేటాబేస్ యొక్క ప్రధాన స్థితిని (canonical state) ఉంచుతుంది. లాగ్స్ ఆపరేషనల్ ట్రేస్‌ను ఉంచుతాయి. ఇన్‌బాక్స్ దేనినీ ఎక్కువ కాలం ఉంచుకోదు.

ఈ చెక్‌లిస్ట్‌ను అనుసరించండి

మీ తదుపరి ఇన్‌ఫ్రాస్ట్రక్చర్ రివ్యూ సమయంలో, పైప్‌లైన్‌ను నిర్వహించే ఇంజనీర్లతో కలిసి ఈ ప్రశ్నలను పరిశీలించండి:

  • ఒక స్థిరమైన operation IDతో మనం ఈమెయిల్‌ను ట్రాస్ చేయగలమా? టైమ్‌స్టాంప్‌లు మరియు ఈమెయిల్ అడ్రస్‌లతో ఐదు వేర్వేరు సిస్టమ్‌లలో మీరు వెతకాల్సి వస్తే, మీ అబ్జర్వబిలిటీ (observability) లోపించినట్లే.
  • లాగ్స్ పూర్తి మెసేజ్ కంటెంట్‌ను నిల్వ చేయకుండా చూస్తున్నాయా? లాగ్ లైన్ ఒక ఈమెయిల్ పంపబడింది అని చెప్పాలి తప్ప, అందులో ఏముందో చెప్పకూడదు.
  • చాలా సిస్టమ్స్‌లో వెరిఫికేషన్ URLలు రిడక్ట్ (redacted) చేయబడ్డాయా? డ్యాష్‌బోర్డ్‌లు, లాగ్స్ మరియు ఎర్రర్ ట్రాకర్లు టోకెన్‌లను మాస్క్ చేయబడిన విలువలుగా (masked values) చూపించాలి.
  • స్టేజింగ్ (staging) ఇన్‌బాక్స్ ఆర్టిఫాక్ట్‌లను షెడ్యూల్ ప్రకారం తొలగిస్తుందా? మాన్యువల్ క్లీనప్ స్టెప్ ఉండకూడదు. ఆటోమేటెడ్ ఎక్స్‌పైరేషన్ మాత్రమే నమ్మదగిన పద్ధతి.
  • సపోర్ట్ టీమ్ స్క్రీన్‌షాట్‌లు లేకుండా డెలివరీ స్టేటస్‌ను తనిఖీ చేయగలరా? ఏజెంట్లు పంపడాన్ని నిర్ధారించడానికి Mailhogని తెరవాల్సి వచ్చినా లేదా స్క్రీన్‌షాట్‌లను చూడాల్సి వచ్చినా, దానికి బదులుగా సరైన స్టేటస్ లుకప్ (status lookup) విధానాన్ని ఏర్పాటు చేయండి.
  • డిబగ్ రికార్డుల కోసం నిర్ణీత రిటెన్షన్ పీరియడ్ ఉందా? మీకు నిజంగా ఎన్ని రోజుల ఎర్రర్ వివరాలు అవసరమో నిర్ణయించుకోండి, ఆపై మీ లాగింగ్ వెండర్ లేదా స్టోరేజ్ బ్యాకెండ్ ఆటోమేటిక్‌గా వర్తింపజేసే పాలసీతో దానిని అమలు చేయండి.

మంచి ప్రైవసీ ఇంజనీరింగ్ అనేది ఎక్కువగా సాధారణమైన ప్రాథమిక నియమాల (boring defaults) గురించి ఉంటుంది. చిన్న చిన్న గార్డ్‌రైల్స్ ఉండటం వల్ల టీమ్‌లు వేగంగా పనులు పూర్తి చేయగలవు, ఎందుకంటే ఒక సాధారణ సపోర్ట్ ప్రశ్న కోసం మూడు సిస్టమ్‌ల ద్వారా వెతకడానికి వారు తక్కువ సమయం కేటాయించాల్సి ఉంటుంది. ఇవి మీ ఆడిట్ ట్రైల్స్‌ను కూడా రక్షించుకుంటాయి. ఒక యూజర్ తన సమాచారాన్ని తొలగించమని కోరినప్పుడు, మీరు ఒక పురావస్తు తవ్వకం (archaeological excavation) చేయవలసి రాదు, కేవలం తనిఖీ చేయాల్సిన few places ల జాబితా మాత్రమే ఉంటుంది.

ఒకే ఒక IDతో ప్రారంభించండి

ఈ నెలలో మీరు కేవలం ఒక మార్పు మాత్రమే చేయాలనుకుంటే, ప్రతి సైన్-అప్ ఈమెయిల్ కోసం ఒకే ఒక operation IDని ఎంచుకుని, దానికి సంబంధించిన ప్రతి సిస్టమ్‌లో దానిని అనుసంధానించండి. రిక్వెస్ట్ వచ్చినప్పుడు మీ API ఎడ్జ్ వద్దే దానిని జనరేట్ చేయండి. దానిని క్యూ చేయబడిన జాబ్‌కు (queued job) జత చేయండి. మీ ఈమెయిల్ ప్రొవైడర్‌కు పంపే మెటాడేటా పేలోడ్‌లో దానిని చేర్చండి. వెబ్‌హుక్స్ (webhooks) ద్వారా దానిని తిరిగి పంపమని ప్రొవైడర్‌ను కోరండి. మీ లాగ్స్‌ను దాని ఆధారంగా ఇండెక్స్ చేయండి. ఒక సపోర్ట్ టికెట్ వచ్చినప్పుడు, మెసేజ్ బాడీని చూడకుండానే, ఆ ఈమెయిల్ పంపడానికి ప్రయత్నించారో లేదో, ప్రొవైడర్ దానిని అంగీకరించారో లేదో మరియు అది బౌన్స్ అయిందో లేదో ఆ ఒక్క స్ట్రింగ్ ద్వారా మీరు సమాధానం చెప్పగలగాలి.

ఈ ఒక్క మార్పు డిబగ్గింగ్ సమయాన్ని గణనీయంగా తగ్గిస్తుంది. ఇది ప్రతి సబ్‌సిస్టమ్‌లో ప్రైమరీ లుకప్ కీగా ఈమెయిల్ అడ్రస్‌లపై ఆధారపడటాన్ని మీ టీమ్ ఆపేలా చేస్తుంది, దీనివల్ల వ్యక్తిగత డేటా డూప్లికేట్ అయ్యే ప్రదేశాలు సహజంగానే తగ్గుతాయి. అక్కడి నుండి, రిటెన్షన్‌ను కఠినతరం చేయడం మరియు సున్నితమైన టోకెన్‌లను రిడక్ట్ చేయడం చాలా సులభం అవుతుంది. లక్ష్యం పరిపూర్ణమైన 'ప్రైవసీ థియేటర్' చేయడం కాదు. వివరించడానికి సులభంగా ఉండేలా, తొలగించడానికి తగినంత చిన్నదిగా ఉండేలా మరియు నిర్వహించడానికి సులభంగా ఉండేలా ఒక పైప్‌లైన్‌ను రూపొందించడం.