MongoDB: Từ "It Works" đến "I Understand Why"

Có một khoảnh khắc mà dev nào cũng từng trải qua: chạy mongosh, thấy connected, thở phào rồi đi tiếp. Nhưng nếu hỏi "tại sao nó connect được?", "connection string kia hoạt động ra sao?", "security rule nào đang mở?" — im lặng.

Mình cũng từng ở đó. Và gần đây, mình quyết định dừng lại, đào sâu hơn vào MongoDB cluster setup, Prisma integration, rồi cả việc planning trước khi code. Bài này không phải tutorial. Đây là những gì mình học được khi chuyển từ "nó chạy" sang "mình hiểu tại sao nó chạy".

MongoDB — Cái gap giữa "connected" và "hiểu tại sao connected"

Mình đang làm việc trực tiếp hơn với cluster setup và environment configuration của MongoDB. Connection strings, security rules, sự khác biệt giữa local và deployed environment — những thứ tưởng nhỏ nhưng lại là nền tảng.

Theo kinh nghiệm của mình, có một sự khác biệt rất rõ giữa hai trạng thái:

• "It connects." — Chạy được, ship thôi.
• "I understand why it connects." — Mình biết tại sao nó chạy, và mình biết khi nào nó sẽ KHÔNG chạy.

Cái thứ hai mới thực sự quan trọng. Vì khi production sập lúc 2 giờ sáng, bạn cần hiểu why, không phải chỉ biết copy-paste connection string từ .env.

Mình bắt đầu document lại mọi thứ:

• Cluster architecture decisions — Tại sao chọn replica set thay vì standalone? Khi nào cần sharding?
• Environment variable handling — .env cho local, secrets manager cho production, và cách chúng khác nhau.
• Schema planning trước khi implement — Nghĩ về data shape trước, code sau.
• Mongo vs relational thinking — Cái này đau đầu nhất. Bỏ thói quen normalize mọi thứ không dễ.

Điều mình thấy hay là: documentation đang dần quan trọng ngang bằng code. Không phải viết doc cho đẹp, mà viết để 3 tháng sau mình mở lại còn hiểu mình đã quyết định cái gì và tại sao.

Prisma + MongoDB — Chậm lại có chủ đích

Khi connect Prisma vào MongoDB, mình buộc phải slow down. Và đây là điều tốt.

Trước đây, workflow của mình khá "brute force": tạo model, chạy thử, lỗi thì sửa, chạy lại. Lặp đi lặp lại cho đến khi nó works. Nhưng lần này mình thử cách khác — nghĩ trước, code sau.

Một số friction mình gặp phải:

• Schema structure decisions — Embed hay reference? Với Mongo, câu trả lời không phải lúc nào cũng giống nhau. Nó phụ thuộc vào access pattern, và Prisma có cách abstract riêng của nó.
• Prisma abstracts Mongo như thế nào — Prisma được sinh ra cho SQL. Khi dùng với Mongo, có những chỗ nó smooth, có những chỗ nó... awkward. Hiểu boundary này giúp mình không bị kẹt.
• Validation logic nên sống ở đâu — Trong Prisma schema? Trong application layer? Hay cả hai? Mình nghiêng về cả hai, nhưng với mức độ khác nhau.

Đây không phải confusion theo kiểu tiêu cực. Đây là loại friction buộc mình phải structure tốt hơn.

Một điều mình muốn chia sẻ thẳng: mình dùng AI như một safety net, không phải architect. Mình design trước, rồi mới verify với AI. Sự khác biệt này quan trọng lắm. Nếu bạn để AI architect cho mình, bạn sẽ có code chạy được nhưng không hiểu tại sao. Quay lại đúng cái gap mình nói ở trên.

Discord Bot — System Design First, Code Second

Project tiếp theo mình đang plan là build một Discord bot from scratch.

Không phải build cho có. Mà để hiểu sâu:

• Event handling — Discord Gateway hoạt động ra sao, WebSocket events được dispatch thế nào.
• Command routing — Slash commands, prefix commands, cách organize command handlers.
• Database syncing — Bot state lưu ở đâu, sync với database ra sao.
• Permission logic — Role-based access, guild-level vs channel-level permissions.
• Deployment flow — Từ local dev đến production, CI/CD cho bot.

Điều khác biệt lần này: mình build planning canvas trước khi viết dòng code đầu tiên.

Theo kinh nghiệm của mình, dev hay rơi vào bẫy "code trước, design sau". Mình cũng vậy. Nhưng càng làm nhiều project, mình càng thấy rằng 2 tiếng planning tiết kiệm được 2 ngày refactor. System design first, implementation second — nghe cliché nhưng đúng thật.

Mình muốn consistency across mọi thứ mình build. Không phải project nào cũng có architecture riêng, mà có một mental framework chung để approach bất kỳ project nào.

Documentation — Từ thói quen thành system

Càng document nhiều về backend decisions và architecture breakdowns, mình càng thấy reusable structure hình thành.

Không phải kiểu template cứng nhắc. Mà là pattern. Cách mình approach một database schema mới, cách mình evaluate trade-offs, cách mình document "tại sao chọn A thay vì B" — những thứ này lặp lại được.

Mình không rush cái này. Nó cần được test qua real builds trước. Nhưng foundation đang ở đó, và mình thấy hứng thú với hướng đi này.

Nếu bạn cũng đang tìm nơi để thảo luận sâu về backend — MongoDB architecture, Prisma patterns, systems thinking — thì mình cũng đang tìm. Không phải kiểu surface-level advice, mà là real engineering conversation. Cứ connect với mình.

Những điều mình rút ra được

• Hiểu "why" quan trọng hơn "how" — Connection string chạy được là chưa đủ. Hiểu tại sao nó chạy mới giúp bạn debug khi nó không chạy.
• Slow down có chủ đích — Friction khi dùng Prisma + Mongo không phải vấn đề. Nó là cơ hội để structure tốt hơn.
• AI là safety net, không phải architect — Design trước, verify sau. Thứ tự này không nên đảo.
• Planning canvas trước code — 2 tiếng design tiết kiệm 2 ngày refactor.
• Documentation là investment — Không phải overhead. Nó là thứ giúp bạn scale kiến thức của chính mình.

Backend work không flashy. Không có UI đẹp để screenshot khoe. Không có animation smooth để record demo. Nhưng cái cảm giác chuyển từ "nó chạy rồi" sang "mình hiểu tại sao nó chạy" — cái đó thay đổi cách mình build mọi thứ. Và một khi đã shift được mindset đó, bạn sẽ không muốn quay lại.