Cosmic Story v2 आर्किटेक्चर — एक सखोल विवेचन.

इंजिनिअर्स, PMs, पत्रकार आणि partnership scouts साठी. संपूर्ण pipeline, चार MongoDB collections, EDA events, V-Model ची काटेकोरता, performance targets, security आणि accessibility — सगळं एकाच पानावर.

  • Soulwise-story हे विद्यमान cosmic-story module सोबतचं एक नवीन NestJS module आहे. feature modules मध्ये थेट import शून्य.
  • चार MongoDB collections: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. AES-256 ने encrypted केलेले bodies, प्रत्येक जे queries handle करते त्यासाठी indexed.
  • 28 s timeout असलेल्या BullMQ queue मार्फत async generation. Events हे database commit झाल्यानंतरच EventEmitter2 द्वारे emit होतात — कोणतेही phantom inbox items नाहीत.
  • V-Model spec: 119 requirements, एकही gap नाही. Backend coverage target services वर 85% statement; frontend Pinia stores वर 90%.

पुन्हा एकदा pipeline, engineering तपशीलासह

प्रत्येक step ला एक service, एक contract, आणि एक event असते.

  1. ट्रिगर

    एखादी user कृती — 'Sister साठी आजचा chapter तयार करा' — किंवा ठरवलेले cron, जसे की रविवारचा 9 a.m. recap, किंवा दर-6-तासांनी होणारे weather refresh.

  2. Queue

    हा job soulwise-chapter-generation नावाच्या BullMQ queue वर येतो, ज्याला 28-सेकंदांचा कडक timeout असतो. जास्त वेळ चालणारे jobs बंद केले जातात आणि user ला 'पुन्हा प्रयत्न करा' असे कळवले जाते.

  3. लिहा

    ChapterGenerationService चार-घटकांचे prompt एकत्र करते — person context, ज्योतिष, signal, cadence — हे सर्व एकाच input मध्ये. कोणतीही raw user PII जशीच्या तशी prompt मध्ये जात नाही; आधी सर्व काही scrub केले जाते.

  4. तयार करा

    AI_GENERATION_ADAPTER symbol टोकनद्वारे एका AI provider ला कॉल केला जातो — हा provider बदलता येतो. पुढे जाण्यापूर्वी response ची लांबी, रचना आणि सुरक्षितता तपासली जाते.

  5. पोस्ट-प्रोसेस करा

    चार गोष्टी घडतात: एक crisis classifier संकटसूचक भाषा तपासतो; एक aspect-chip extractor एक ते तीन ज्योतिष chips काढतो; एक anti-claim filter निषिद्ध शब्दरचना काढून टाकतो; आणि platform-managed key वापरून body AES-256 ने encrypt केली जाते.

  6. साठवा

    हा artifact योग्य त्या MongoDB collection मध्ये लिहिला जातो — chapters, journal entries, resonances — आणि जलद शोधासाठी userId व personId indexes सोबत. आधी soft-delete; PII चे hard-delete 30 दिवसांनी.

  7. सूचित करा

    database commit नंतर एक EventEmitter2 event — CHAPTER_COMPLETED, JOURNAL_CREATED — fire होते. notifications module ते उचलतो, एक inbox item तयार करतो आणि पर्यायाने एक push पाठवतो (दिवसातून एकदाच मर्यादित, quiet hours चा आदर राखत).

  8. दाखवा

    frontend एका authenticated API call द्वारे artifact आणतो. Hub नवीन content सह पुन्हा render होतो. वापरकर्ता offline असेल, तर cache कालचा view दाखवतो आणि पुन्हा connect झाल्यावर नवीन artifact दिसतो.

trigger पासून surface पर्यंत सात टप्पे, प्रत्येकाला तो प्रत्यक्षात काय करतो त्यावरून नाव दिले आहे.

चार collections

प्रत्येक collection ज्या queries ना उत्तर देते त्यासाठी indexed.

soulwise_persons

Album entries. userId, status, deletedAt वर indexes. आधी soft-delete; PII चे hard-delete 30 दिवसांनी.

soulwise_chapters

AI ने लिहिलेले chapters, encrypted body. personId, userId, generatedAt वर indexes. जलद filtering साठी aspect chips वेगळ्या array मध्ये साठवलेले.

soulwise_journal_entries

User ने लिहिलेली reflections, encrypted body. userId, personId, createdAt वर indexes. Search साठी text-indexed body. प्रत्येक entry साठी 'private — Luminara ला feed करू नका' flag.

soulwise_resonances

प्रत्येक bond साठी चार-dimension scores. personId वर unique index. Chapter किंवा journal write झाल्यानंतर service call मार्फत पुन्हा गणना होते.

EDA इव्हेंट्स

कडक नियम: इव्हेंट्स फक्त डेटाबेस commit झाल्यानंतरच fire होतात. क्रॉस-मॉड्यूल dependencies Symbol injection tokens मार्फत असतात, कधीही forwardRef मार्फत नाही. feature modules दरम्यान थेट service-to-service imports नाहीत.

  • SoulwiseEvents.CHAPTER_COMPLETED — SoulwiseEvents.CHAPTER_COMPLETED — एखादा chapter encrypt आणि persist झाल्यानंतर fire होतो. Notifications-v2 ऐकते; inbox item तयार करते; गरज भासल्यास push पाठवते.
  • SoulwiseEvents.JOURNAL_CREATED — SoulwiseEvents.JOURNAL_CREATED — एखादी journal entry encrypt आणि persist झाल्यानंतर fire होतो. Resonance service ऐकते; recompute trigger करते.
  • SoulwiseEvents.PERSON_BIRTH_UPDATED — SoulwiseEvents.PERSON_BIRTH_UPDATED — एखाद्या व्यक्तीचा जन्म-डेटा बदलल्यानंतर fire होतो. सिनास्ट्रि cache invalidate होते.
  • SoulwiseEvents.PUSH_REQUESTED — SoulwiseEvents.PUSH_REQUESTED — notifications-v2 contract नुसार; push budget आणि quiet hours पाळतो.

V-Model spec काटेकोरता

119 traceable requirements, शून्य त्रुटी. प्रत्येक requirement पुढे एका test case शी (UTP, ITP, STP, E2E) आणि मागे एका user story शी जोडली जाते. 20 user stories. 15 functional requirements. 12 non-functional categories. 8 global acceptance gates.

कामगिरीचा करार

Chapter generation 95% requests साठी 30 सेकंद किंवा त्याहून जलद, BullMQ job duration distribution नुसार मोजलेले. API p99 GET latency 1,000 concurrent users वर 500 ms किंवा त्याहून जलद, k6 load test मार्फत मोजलेले. Frontend TTI सिम्युलेटेड 4G वर 3 सेकंद किंवा त्याहून जलद, Lighthouse CI मार्फत मोजलेले.

सुरक्षा करार

journal आणि chapter bodies साठी platform-managed keys वापरून rest वर AES-256 encryption. transit मध्ये TLS 1.2+; HTTP→HTTPS redirect. 1-तास lifetime असलेले JWT access tokens, 30-दिवस lifetime असलेले refresh tokens, refresh वर rotation. PII च्या hard-delete पूर्वी 30-दिवस window सह soft-delete.

Accessibility करार

prefers-reduced-motion जगभर पाळला जातो — GSAP animations फक्त opacity-only fades होतात. प्रत्येक interactive element वर VoiceOver आणि TalkBack labels असतात. प्रत्येक release आधी iOS आणि Android वर हे स्वतः तपासले जाते.

cosmic-story वाढवण्याऐवजी वेगळा soulwise-story module का?

कारण upstream spec हे feature पुन्हा नव्याने उभारतो, आणि आधीच असलेल्या module मध्ये पुनर्बांधणी केली तर एकतर v1 चा अनुभव बिघडेल किंवा नंतर fork करून merge करावं लागेल. नवा module v1 ला तसंच ठेवतो, v2 ला सिद्ध होऊ देतो, आणि तयार झाल्यावर स्वच्छपणे migrate होतो.

Postgres नाही तर MongoDB का?

सध्याचं My Zodiac AI backend MongoDB वर आहे; ते बदलणं म्हणजे या feature शी संबंध नसलेला infrastructure निर्णय होईल. document model हे chapters आणि journal entries साठीही उत्तम बसतं — nested, वेगवेगळ्या लांबीचं, encrypted-as-blob.

queue साठी BullMQ ची निवड का?

BullMQ हे Redis वर चालतं, जे session आणि rate-limit साठी आधीच stack मध्ये आहे. नवं infrastructure नाही. आतमध्येच असलेले retry, timeout आणि observability हे chapter-generation च्या गरजा custom plumbing शिवाय पूर्ण करतात.

upstream spec खरंच कुठे लिहून ठेवलाय?

Internal repo मध्ये. या पानावरील आकडे आणि contracts हे upstream V-Model artifacts चं सारांशरूप आहेत. My Zodiac AI च्या blog cluster वरचे सार्वजनिक engineering blog posts ('cosmic-story-v2' tag असलेले) build च्या विशिष्ट भागांत अधिक खोलात जातात.

My Zodiac AI आजच वापरून पाहा

Soulwise आपल्या लाटा उघडत असतानाच, आमचं फ्लॅगशिप ज्योतिष app आधीच तुमच्या हातात आहे.

यावर डाउनलोड कराApp Storeयावर मिळवाGoogle Play

ज्योतिष आशय हा चिंतन आणि मनोरंजनासाठी आहे. इथे वर्णन केलेली Cosmic Story v2 ची वैशिष्ट्ये विकासाधीन आहेत; उपलब्धता पूर्वसूचनेशिवाय बदलू शकते.