Joung Hun Park

Why a Monorepo? A monorepo is a single repository containing multiple distinct projects, with well-defined relationships. — Monorepo Explained A monorepo makes sense when multiple projects have meaningful relationships: Shared libraries and utilities — reuse common code across projects. Shared contracts — keep API types consistent between producers and consumers. Cross-project changes — update related projects in a single change. Shared tooling and rules — maintain consistent development practices.

After deciding to use microservices, the next question was: How should I organise the codebase? I chose a monorepo. Second-Memory has several applications and services: apps/ web/ mobile/ services/ memory-service/ ask-service/ embedding-worker/ packages/ api-types/ ui-components/ They are independently deployable, but they are all part of the same product. Monorepo vs Polyrepo There is no universally better choice.

The previous post covered why I chose pgvector for semantic search. But there was another question: When should a memory be embedded? At first, it might seem simple: Create memory ▼ Generate embedding ▼ Save embedding But this makes memory creation dependent on the embedding process. If the embedding provider is slow or unavailable, creating a memory could also fail or become slow. I wanted to separate these two operations.