DEV Community: Joung Park

Monorepo or Polyrepo?

Joung Park — Wed, 07 Oct 2026 05:52:16 +0000

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 trade-offs become clearer when looking at common development tasks:

Area	Monorepo	Polyrepo
Share code	Easy — reusable code can live in shared packages	Harder — publish packages or duplicate code
Share types	Easy — TypeScript types can be shared directly	Harder — types need separate versioning
Cross-project changes	Easy — related changes can be made in one PR	Harder — changes may require multiple PRs
Dependency management	Easy — dependencies can be managed consistently	More complex — each repo manages its own dependencies
Local development	Easy — one repository contains the whole system	More setup — multiple repositories need to be configured
CI/CD	More complex — need to detect affected projects	Easy — each repository naturally has its own pipeline
Service isolation	Harder — boundaries need to be enforced within the repository	Easy — repositories provide natural isolation
Access control	Harder — repository access generally covers the whole codebase	Easy — permissions can be managed per repository
Independent releases	Possible — CI/CD can deploy projects independently	Easy — each repository has its own release lifecycle

Neither approach is inherently better.

For Second-Memory, I valued easy development across the whole system more than repository-level isolation.

When to Choose Which

A monorepo can be a good fit when:

Small team or solo developer — one repository is easier to manage than several.
Projects share contracts or code — changes can be made and tested together.
Cross-project changes are common — one PR can update multiple applications or services.
The whole system is closely related — one repository makes it easier to understand and work across the product.

Polyrepo can be a better fit when:

Large or independent teams need clear ownership boundaries.
Strong repository isolation is important.
Projects have different release cycles.
Access control needs to differ between projects.

For Second-Memory, being a sole developer was one of the main reasons I chose a monorepo.

Managing several repositories would add overhead without giving me much benefit. I didn't need repository-level ownership boundaries between teams.

Instead, I wanted to make it easy to work across the web app, mobile app, backend services, and shared contracts.

What Should Be Shared?

A monorepo makes sharing easy.

But easy to share doesn't mean everything should be shared.

I wanted to keep the shared surface area small.

Shared Part	Used By	Why Share It?
API types	Web, Mobile, Backend	Keep API contracts consistent
Web-specific code	Web	Keep it inside `apps/web`
Mobile-specific code	Mobile	Keep it inside `apps/mobile`
Service domain logic	Individual service	Keep ownership within the service
Service implementation	Individual service	Preserve service boundaries

So instead of creating shared packages for everything, I only create a package when there is a genuine reason to share something.

For example:

apps/
  web/
  mobile/
services/
  memory-service/
  ask-service/
  embedding-worker/
packages/
  api-types/
  ui-components/

The API types are shared because they represent a contract between different parts of the system.

But a Web-only component stays in apps/web.

A Mobile-only utility stays in apps/mobile.

And Memory Service domain logic stays inside memory-service.

Share the contract, not the ownership

The fact that services live in the same repository doesn't mean they should share their internal implementation.

The API contract can be shared:

flowchart TB
    T[packages/api-types]

    W[Web] --> T
    M[Mobile] --> T
    B[Backend Services] --> T

while the services remain independently owned:

flowchart TB
    MS[Memory Service]
    AS[Ask Service]

    MS --> MD[Memory Domain]
    AS --> AD[AI Interaction]

    MD --> DB1[(Memory DB)]
    AD --> DB2[(Ask Data)]

Share contracts where it makes sense, but don't share service ownership.

Keeping the Shared Surface Small

There is another practical reason for limiting shared code.

The more projects depend on a shared package, the larger the potential impact of a change.

For example:

flowchart TB
    S[packages/shared]
    S --> W[Web]
    S --> M[Mobile]
    S --> ME[Memory]
    S --> A[Ask]

A change to shared may require all projects to be tested.

But a change here:

flowchart LR
    C[Change in apps/web] --> W[Web]
    W --> CI[Web CI/CD]

only affects Web.

This has implications for both CI/CD and application dependencies.

I don't want a large shared package that contains unrelated functionality used by almost every project.

Instead, I prefer small, focused shared packages with clear reasons for existing.

The CI/CD Trade-off

CI/CD is one area where polyrepo can be simpler.

With polyrepo, a change to memory-service naturally belongs to the memory-service repository.

flowchart TB
    R[memory-service repo]
    R --> CI[CI/CD]
    CI --> T[Test]
    CI --> B[Build]
    CI --> D[Deploy]

In a monorepo, multiple deployable units live in the same repository.

A change to:

services/memory-service/

shouldn't necessarily rebuild and deploy everything.

The pipeline needs to understand:

what changed
what depends on it
what needs to be tested
what needs to be built
what needs to be deployed

This becomes particularly important when shared packages are involved.

A change to ui-components may affect only web and mobile projects, while a change isolated to services/embedding-worker/ should ideally affect only the relevant pipeline.

The repository structure itself is simple, but the build and deployment system needs to become more intelligent as the project grows.

Why Monorepo for Second-Memory?

The main benefits for me were:

Easy sharing of API types
Easy cross-project changes
Easy local development
Easy dependency management
Easy visibility of the whole product
Less overhead for a solo developer

The trade-offs were:

More complex CI/CD
More tooling needed as the repository grows
Less repository-level isolation
The need to carefully control shared dependencies

For Second-Memory, I was willing to accept these trade-offs.

The goal wasn't to share as much code as possible.

The goal was to get the convenience of a monorepo while keeping ownership and dependencies clear.

That led to the next question:

How do I manage builds, dependencies, task execution, and caching across all these projects?

Microservices or Monolith?

Joung Park — Wed, 07 Oct 2026 04:18:28 +0000

The initial architecture had three main backend responsibilities:

Memory Service
Ask Service
Embedding Worker

But there was another architectural decision behind this:

Why make them separate services instead of building one backend?

A monolith would have been simpler.

For a small application, it would probably have been enough.

I still chose a microservice architecture for Second-Memory for three main reasons.

1. Clear boundaries

Memory and Ask have different responsibilities.

The Memory Service owns the memory domain:

create and manage memories
persist memory data
generate/retrieve relevant memories
manage embeddings

The Ask Service owns the AI interaction:

receive questions
retrieve relevant context
construct prompts
call the LLM
return the answer

They work together, but they represent different responsibilities.

I wanted those boundaries to exist at the service level rather than only as modules inside one application.

flowchart LR
    A[API Gateway] --> B[Memory Service]
    A --> C[Ask Service]
    B -.-> D[Memory + Vector]
    C -.-> E[LLM]

The Embedding Worker is separated for a different reason.

Embedding generation is asynchronous work and doesn't need to be part of the request that creates a memory.

flowchart LR
    A[Memory Service] --> B[Outbox]
    B --> C[Queue]
    C --> D[Embedding Worker]

The boundaries therefore follow the responsibilities and execution models of the system.

2. A system for learning AI engineering

Second-Memory is also a project for exploring how AI systems are built.

I didn't want the architecture to stop at:

flowchart LR
    A[Application] --> B[LLM API]

The system gave me an opportunity to work with several patterns that are common in production AI systems:

asynchronous processing
queues
workers
embeddings
vector search
retrieval
service-to-service communication
LLM integration

Using separate services makes these boundaries explicit and gives me a way to experiment with each part independently.

The goal isn't to use microservices simply because they are popular.

The architecture should help me learn and validate how these pieces work together as a real system.

3. Production readiness and scaling

I also wanted to design Second-Memory as something that could eventually grow into a production system.

The different components have different scaling characteristics.

If memory creation increases, I may need more Memory Service instances.

If embedding jobs increase, I can scale the workers independently.

If AI requests become the bottleneck, the Ask Service can scale independently.

This doesn't mean I need to scale everything independently today.

It means the architecture doesn't force unrelated workloads into the same deployment unit.

What about a monolith?

A monolith would still be a reasonable choice for Second-Memory.

It would have:

less infrastructure
simpler deployment
simpler local development
fewer service-to-service calls
less operational overhead

So why accept the additional complexity?

Because my goal wasn't only to build the simplest V1.

I wanted to build a system with clear boundaries that could evolve toward production scale, while giving me a practical environment to explore AI system architecture.

The trade-off was intentional.

I chose microservices not because a monolith couldn't work, but because the boundaries, asynchronous workloads, learning goals, and potential scaling characteristics made the additional complexity worthwhile.

Why the Outbox Pattern, Queue, and Embedding Worker?

Joung Park — Wed, 07 Oct 2026 03:47:01 +0000

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.

The architecture became:

Memory Service
      ▼
 PostgreSQL
      ▼
 Outbox Table
      ▼
 Queue / Job Runner
      ▼
 Embedding Worker
      ▼
 pgvector

1. The Outbox Pattern

When a user creates a memory, the Memory Service writes the memory and an outbox event in the same database transaction.

For example:

Transaction
┌─────────────────────────────┐
│ INSERT memory               │
│ INSERT outbox event         │
└─────────────────────────────┘

The important part is that they succeed or fail together.

This avoids a common problem with distributed systems:

Memory saved
     ▼
Embedding event lost

The outbox gives me a durable record of the work that needs to happen.

The outbox is not the queue itself.

It is a reliable bridge between the database transaction and asynchronous processing.

2. The Queue / Job Runner

A separate process reads pending outbox events and puts jobs onto a queue.

Outbox
   ▼
Queue
   ▼
Embedding Worker

This gives the embedding process some useful properties:

asynchronous processing
retries
independent scaling
failure isolation
no need to block the memory API

The user can save a memory without waiting for the embedding provider.

3. The Embedding Worker

The embedding worker has one main responsibility:

turn memory text into an embedding and store it in pgvector.

flowchart TD
    A[Get Memory] --> B[Generate embedding]
    B --> C[Store Vector]

This keeps embedding-specific logic out of the Memory Service's synchronous request path.

It also gives me a place to evolve the embedding pipeline later.

For example, I could change:

embedding models
chunking strategy
retry behaviour
batch processing
embedding dimensions

without changing the API used to create a memory.

4. Why asynchronous?

There is an important consequence of this design:

A newly created memory may not be immediately searchable.

There can be a small delay between:

Memory created
     │ asynchronous processing
     ▼
Embedding created
     ▼
Memory available for semantic search

I accepted this trade-off.

For Second-Memory, immediate persistence is more important than making the embedding operation part of the user's request.

This is essentially eventual consistency between the memory record and its vector representation.

5. Failure becomes easier to handle

The asynchronous design also changes how failures work.

If the embedding provider temporarily fails:

Memory
  ▼
Outbox
  ▼
Queue
  ▼
Embedding Worker - X -> Retry

The memory itself has already been safely stored.

The embedding job can be retried without asking the user to submit the memory again.

That separation was important to me.

The decision

The final flow became:

graph TD
    CM[Create Memory] --> PG

    subgraph PG [PostgreSQL]
            M[Memory]
            OE[Outbox Event]
    end

    OE --> Q[Queue]
    Q --> EW[Embedding Worker]
    EW --> PV[(pgvector in PostgreSQL)]

Each part has a different responsibility:

Component	Responsibility
Memory Service	Store the memory
Outbox	Reliably record the event
Queue	Deliver asynchronous work
Embedding Worker	Generate embeddings
pgvector	Store and search vectors

This added some complexity compared with simply generating the embedding inside the API request.

But it gave me something more important:

memory creation is no longer tightly coupled to the availability of the embedding pipeline.

That was the trade-off I wanted.

Vector database

Joung Park — Wed, 07 Oct 2026 03:34:17 +0000

Second-Memory stores things a user writes over time.

If a user later asks:

“What did I write about performance problems?”

A normal keyword search isn't always enough.

The memory might say:

“The database becomes slow when thousands of users query it at the same time.”

There may be no exact keyword match between the question and the memory.

This is where semantic search becomes useful.

1. From text to vectors

I can convert a piece of text into an embedding — a vector representation of its meaning.

For example:

"The database becomes slow when thousands of users query it at the same time."
         ↓
[Embedding model]
         ↓
[0.021, -0.183, ...]

The actual vector contains many dimensions, so it isn't meaningful to look at the individual numbers.

What matters is the relationship between vectors.

Texts with similar meanings tend to have vectors that are closer together.

So when a user asks a question, I can:

Question
Embedding
Vector similarity search
Relevant memories

This gives Second-Memory a way to retrieve memories based on meaning, rather than just matching words.

2. Why pgvector?

Once I decided to use embeddings, I needed somewhere to store and search them.

I considered:

	pgvector	Pinecone
Vector search	Yes	Yes
Relational data	Yes	No
Existing PostgreSQL	Yes	No
Separate infrastructure	No	Yes
Operational complexity	Lower	Higher
Good fit for V1	Yes	Yes

I chose pgvector.

The main reason wasn't that pgvector is necessarily better than Pinecone.

It was that Second-Memory already had a natural place for the vectors:

the Memory Service's database.

With pgvector, I could keep the memory and its embedding together.

erDiagram
    "Memory Service" ||--|| "PostgreSQL + pgvector" : utilizes
    "PostgreSQL + pgvector" ||--|{ Memory : contains

    Memory {
        uuid user_id
        text content
        vector embedding
    }

That kept the architecture simple.

3. Why not introduce a vector database?

A dedicated vector database could make sense at larger scale.

But introducing one also creates another system to operate and another boundary to manage.

For V1, I didn't see enough benefit to justify that complexity.

The Memory Service could own:

memory data
embeddings
vector search

all within the same data boundary.

That also reinforced one of the architectural principles from the previous post:

The service that owns the data should own access to it.

The Ask Service doesn't need to know whether semantic search is implemented with pgvector, Pinecone, or something else.

It simply asks the Memory Service for relevant memories.

4. What this gives me

With pgvector, the basic retrieval flow becomes:

User question
      ↓
Generate query embedding
      ↓
Memory Service
      ↓
pgvector similarity search
      ↓
Relevant memories
      ↓
Ask Service
      ↓
     LLM

This is the first important piece of the AI architecture.

The LLM doesn't need to know everything the user has ever written.

Instead, the system retrieves the memories that are most relevant to the current question and uses those as context.

The decision

For Second-Memory V1, I chose:

PostgreSQL + pgvector

because it gave me semantic search without introducing another database.

It was a pragmatic choice:

vector search
relational data
one data boundary
less infrastructure
simpler development

The First Architecture Draft

Joung Park — Wed, 07 Oct 2026 03:24:36 +0000

I had the product definition, user stories, and backlog.

Now it was time to design the system.

I started with the main responsibilities of Second-Memory and came up with my first architecture draft:

flowchart 
    W[Web Client] --> G[API Gateway / BFF]
    M[Mobile Client] --> G

    G --> A[Auth]
    G --> MS[Memory Service]
    G --> AS[Ask Service]

    MS --> D[(Database)]
    MS --> V[(Vector DB)]

    AS --> L[LLM Provider]

    AS --> MS

The diagram itself is fairly simple, but there were several design principles behind it.

1. BFF for the clients

Both the web and mobile clients communicate through the API Gateway / BFF.

I chose the Backend for Frontend (BFF) pattern so that the clients don't need to communicate directly with the internal services.

The BFF provides a client-facing API while hiding the internal architecture.

It also gives me a place to handle things such as authentication, routing, and client-specific requirements.

This means the clients don't need to know whether a request is handled by the Memory Service, Ask Service, or something else.

The internal architecture can evolve without making the clients aware of every change.

2. Each service owns its data

One principle I wanted to follow was:

Don't share databases between services.

A service owns the data that belongs to its responsibility.

In this architecture, the Memory Service owns both the database and vector database.

If another service needs memory data, it doesn't connect directly to either database.

Instead, it calls the Memory Service through an internal API.

For example:

flowchart 
    AS[Ask Service] -->|Internal API| MS
    MS[Memory Service] --> D[(Database)]
    MS --> V[(Vector DB)]

This keeps the data ownership clear and prevents other services from becoming coupled to the Memory Service's storage implementation.

If the storage implementation changes later, the other service shouldn't need to know.

3. Separation of concerns

Each component has a specific responsibility.

The BFF deals with client-facing communication.

The Memory Service deals with memory.

The Ask Service deals with the AI interaction.

The LLM generates the response.

The databases provide persistence.

This separation makes the architecture easier to reason about.

It also means that AI-specific logic doesn't have to spread throughout the rest of the application.

4. DDD and bounded contexts

The separation between Memory Service and Ask Service wasn't just about splitting the code into smaller services.

I was thinking about the different domains and responsibilities involved.

The Memory Service represents the memory domain:

creating memories
retrieving memories
searching memories
managing memory data

The Ask Service represents the AI interaction:

receiving a question
deciding what information is needed
requesting relevant memories
constructing context
calling the LLM
generating the answer

They are closely related, but they are not the same responsibility.

This is where the idea of bounded contexts from Domain-Driven Design helped me think about the boundaries.

The Ask Service uses the Memory Service, but it doesn't become responsible for managing memory itself.

5. Encapsulation and API contracts

The service boundary also creates an important form of encapsulation.

The Ask Service doesn't need to know how the Memory Service stores or searches memories.

It only needs to know what the Memory Service provides through its API.

For example, the Ask Service might ask for relevant memories, without knowing whether the Memory Service uses PostgreSQL, pgvector, a different vector store, or some other implementation in the future.

The API becomes the contract between the services.

This keeps implementation details inside the service that owns them.

These principles gave me the initial structure of Second-Memory.

It wasn't a complicated architecture, and that was intentional.

I wanted clear boundaries without creating unnecessary complexity.

With the boundaries in place, I could start looking at the individual technical decisions.

Putting on the Product Owner Hat

Joung Park — Wed, 07 Oct 2026 02:59:25 +0000

I had the idea for Second-Memory.

But at that point, it was still just an idea. It was too vague to start thinking about architecture or implementation.

I wanted to develop the idea further before I started building it.

So I put on the Product Owner hat.

I followed the kind of process I had experienced in my professional work.

I started by defining the initiative. I wrote down what I was trying to achieve and what I wanted the product to be.

Then I wrote a PRD.

Writing it made me think through the product in more detail: the problem, the user, the main use cases, the scope, and what I wanted to achieve with the first version.

From there, I created user stories.

This helped me look at the product from the user's perspective rather than thinking about how I was going to implement it.

I then organised the stories into an initial backlog and broke the work down into tasks that I could eventually implement.

There was another reason I wanted to document all of this.

I knew I would be using AI tools to help me build the project.

Instead of explaining the project from scratch every time I asked an AI coding tool for help, I could give it the product documents as context.

The PRD and user stories became a shared reference point — for me as the developer, and for the AI tools I was working with.

The idea started in my head as something fairly vague.

By the end of this process, I had something much more concrete:

an idea → a product definition → user stories → work I could build.

AI Project Idea

Joung Park — Wed, 07 Oct 2026 02:57:54 +0000

I Wanted an AI That Would Just Listen

I wanted to learn how to build AI systems.

So I started looking for a project.

At the time, I was using ChatGPT like everyone else. I would type something, and it would answer.

That's what makes a chatbot useful.

But I started thinking about something different.

Sometimes I don't want an answer.

Sometimes I don't want advice.

I don't want another question.

I just want to write down what I'm thinking.

A thought.

An idea.

Something that happened today.

A feeling.

Something I'm not even sure is important yet.

Just like talking to myself.

What if the AI didn't respond?

Imagine opening an AI application and writing:

"I've been thinking about learning AI more seriously. I don't know where this will take me, but I feel like I should start building something."

And then...

Nothing.

No advice.

No suggestions.

No follow-up question.

It just keeps it.

That's it.

Then a few weeks later, I could ask:

"What have I been thinking about learning AI?"

And now the system responds.

Not based on a generic conversation.

Not based on what I happened to tell it five minutes ago.

But based on the things I had previously written down.

That was the idea behind Second-Memory.

A different kind of AI interaction

Most chatbots are built around a simple interaction:

You → AI → You → AI → You

Every message expects a response.

I wanted something different:

Me → Second-Memory

...

And only when I have a question:

Me → Second-Memory → Answer based on what I've written

The system isn't there to constantly talk to me.

It's there to remember.

That's where the name came from:

Second-Memory.

A place where I can put the things I might otherwise forget.

Why build this?

This started as an AI learning project.

I wanted to understand what it actually takes to build an AI-powered system rather than simply calling an LLM API.

And this idea seemed like a good problem to explore.

How do you store someone's thoughts?

How do you find the relevant ones later?

How do you understand that two thoughts written months apart might be related?

How do you give an AI enough context to answer a question without giving it everything?

How do you know whether the answer is actually grounded in what the person wrote?

I didn't know the answers yet.

I just had the idea.

So I created a repository.

The first commit was:

second-memoryYour second memory - capture today, remember forever

And that's where the project began.