This week I tried to answer it for my own project. I am building rag-service, a retrieval-augmented generation API in NestJS with PostgreSQL and pgvector. I had just read the creational patterns on refactoring.guru, written the toy examples, and felt reasonably confident. Then I tried to apply one of them to real code, and it took me much longer than the toy version did. That gap is what this post is about.

The problem, stated plainly

Here is what my embedding code looked like:

@Injectable()
export class EmbeddingService {
  private readonly openai: OpenAI;

  constructor(private readonly configService: ConfigService) {
    this.openai = new OpenAI({
      apiKey: this.configService.get<string>('OPENAI_API_KEY'),
    });
  }

  async embed(text: string): Promise<number[]> {
    const response = await this.openai.embeddings.create({
      model: 'text-embedding-3-small',
      input: text,
    });
    return response.data[0].embedding;
  }
}

Nothing is wrong with this code in isolation. It works. The issue appears only when you look at who depends on it. Both DocumentService (which ingests documents) and SearchService (which answers questions) import this concrete class directly. So every time I ingest a test document during development, I pay OpenAI. Without an API key, the app cannot do anything useful at all. And if I ever want to try a local embedding model, I have to open both services and change them.

Notice that none of these are hypothetical. The first one costs me money every day. This is the "new Truck() everywhere" problem from the textbook, except the truck is a paid API.

Step 1: say what you need, not who provides it

The first move is to describe what the services actually need from an embedder. Not a name, not a model, just a capability: give me a text, I give you a vector.

// embedding-provider.ts
export interface EmbeddingProvider {
  embed(text: string): Promise<number[]>;
}

export const EMBEDDING_PROVIDER = 'EMBEDDING_PROVIDER';

My first attempt at this interface had name and description fields. That was a mistake worth noting, because I think it is a common one. An interface should describe behaviour, what the thing does, not properties, what the thing is. The services never ask the embedder for its name. They ask it for vectors.

The second line, the string constant, looks strange at first. Why do we need it? I will come back to this, because it turned out to be the most instructive part of the whole exercise.

Step 2: two implementations

The real one is the old service, moved almost unchanged:

// openai-embedding.provider.ts
export class OpenAIEmbeddingProvider implements EmbeddingProvider {
  private readonly openai: OpenAI;

  constructor(apiKey: string) {
    this.openai = new OpenAI({ apiKey });
  }

  async embed(text: string): Promise<number[]> {
    const response = await this.openai.embeddings.create({
      model: 'text-embedding-3-small',
      input: text,
    });
    return response.data[0].embedding;
  }
}

One change: the constructor takes a plain apiKey string instead of ConfigService. The provider no longer knows that NestJS exists. Reading configuration is somebody else's job, and as a side effect the class becomes trivial to construct in a test.

The fake one is a single line:

// fake-embedding.provider.ts
export class FakeEmbeddingProvider implements EmbeddingProvider {
  async embed(text: string): Promise<number[]> {
    return new Array(1536).fill(0.01);
  }
}

That line hides two decisions, and both came from mistakes. More on that below.

Step 3: the factory

Now something has to decide which implementation to use. In NestJS, that place is the module, through useFactory:

// embedding.module.ts
@Module({
  providers: [
    {
      provide: EMBEDDING_PROVIDER,
      inject: [ConfigService],
      useFactory: (config: ConfigService): EmbeddingProvider => {
        if (config.get<string>('EMBEDDING_PROVIDER') === 'fake') {
          return new FakeEmbeddingProvider();
        }
        return new OpenAIEmbeddingProvider(
          config.getOrThrow<string>('OPENAI_API_KEY'),
        );
      },
    },
  ],
  exports: [EMBEDDING_PROVIDER],
})
export class EmbeddingModule {}

I used getOrThrow for the API key on purpose. config.get returns undefined silently when a variable is missing, which means a typo in .env shows up much later as a confusing error from OpenAI. getOrThrow fails at startup, where the cause is obvious.

The services now ask for the token, not the class:

constructor(
  @Inject(PG_POOL) private readonly pool: Pool,
  @Inject(EMBEDDING_PROVIDER) private readonly embedder: EmbeddingProvider,
) {}

After this change, the word OpenAI does not appear anywhere in DocumentService or SearchService. Setting EMBEDDING_PROVIDER=fake in .env makes the whole ingestion pipeline run without a single network call. No code changes, only configuration.

A note on honesty: this is not the Factory Method

I should be careful about naming here, because it is easy to inflate what one has done. The GoF Factory Method relies on inheritance: an abstract creator declares a factory method, and subclasses override it. What I wrote above has no inheritance at all. It is one function with an if. This is usually called a Simple Factory.

I wrote the inheritance version too, as an exercise, and it works. But in a framework with a dependency injection container, the container already does the job that subclassing was invented for. So the simpler form is the one you will actually meet in backend code. I think it is more useful to know why the two differ than to pretend the simpler one is the textbook one.

Incidentally, the same file that holds my database pool uses exactly this shape:

{
  provide: PG_POOL,
  inject: [ConfigService],
  useFactory: (config: ConfigService) =>
    new Pool({ connectionString: config.get<string>('DATABASE_URL') }),
}

Nest runs that factory once and hands every service the same Pool. That is a Singleton, managed by the container rather than written by hand. I had been using two patterns for weeks without noticing.

Three things the tutorials did not mention

1. Interfaces do not exist at runtime

Back to the string constant. In a toy example you write new FakeIngestion() and everything is visible. In NestJS, dependencies are resolved at runtime, and TypeScript interfaces are erased when the code is compiled to JavaScript. The container cannot look up EmbeddingProvider because, at runtime, there is no such thing. A string token is the only handle that survives compilation.

I had already met this idea in a different form. In my Singleton exercise, I marked the constructor private and then called new AppConfig() anyway, to see the error. With plain node, which strips types without checking them, it ran without complaint and created a second instance. TypeScript's private is a compile-time promise, not a runtime wall. It is the same lesson twice: what the type system says and what the program does are two different things.

2. TS1272

Once I injected the interface, the compiler stopped with this:

TS1272: A type referenced in a decorated signature must be imported with
'import type' or a namespace import when 'isolatedModules' and
'emitDecoratorMetadata' are enabled.

It is the same issue again, from another angle. Nest asks the compiler to emit type metadata for decorated constructor parameters. For a class that works, because the class exists at runtime. For an interface there is nothing to emit, so TypeScript asks you to state explicitly that this import is only a type:

import { type EmbeddingProvider, EMBEDDING_PROVIDER } from '../embeddings/embedding-provider';

type applies only to the interface. The token is a real value and stays a normal import.

3. The fake vector has to respect the database

My first fake embedder returned three numbers, as in my exercise. It compiled. It would have failed on the first insert, because the column is defined as VECTOR(1536) and pgvector rejects anything of another dimension. The type number[] says nothing about length, so the compiler cannot help you here. The database schema is part of the contract, even if it is not written in TypeScript.

My second attempt filled the array with zeros, which is also wrong in a quieter way. Cosine distance divides by the length of the vector, and a zero vector has length zero, so the distance is undefined. Hence 0.01.

One more caveat, so nobody misreads what the fake is for. Every fake vector is identical, so every chunk is equally "similar" to every question. The fake lets you test that the pipeline runs: chunking, inserting, querying, error handling. It tells you nothing about retrieval quality. And if you ingest documents with the fake and later switch back to OpenAI, those rows still hold fake vectors and should be re-embedded.

What I take from this

The pattern itself was the easy part. I understood the diagram in an afternoon. What took time was everything around it: the runtime model of the framework, the gap between types and values, a constraint that lives in SQL rather than in TypeScript. None of that is in the catalogue, and all of it is what an actual codebase forces you to confront.

So when someone asks me now what the Factory pattern is for, I hope I will not draw boxes. I will say: it is what let me stop paying for API calls I did not need, and it taught me that interfaces disappear at runtime. That answer is less elegant, but I think it is more true.

A note on how this was written: the refactor, the code and every mistake described here are mine. I used Claude as a writing assistant to draft the post from my notes and code, then reviewed and edited every line.

The code is on GitHub: YusufOztoprak/rag-service. My weekly study notes, including the exercise versions of Factory Method, Singleton and Builder, are in learning-notes.

This week's goal was observability. For every request I wanted to know three things:

1. Which request a log line belongs to (a request ID that also works across both services)

2. How long it took — and how much of that was OpenAI vs. my own code

3. How many embedding tokens it consumed, because tokens are money

The catch: evorag follows Clean Architecture, and I didn't want any of this to leak into the domain or use-case layers.

The constraint: the dependency rule

The project is laid out like this:

src/evorag/
  domain/          Chunk entity (plain frozen dataclass)
  ingestion/       IngestDocument use case + ports
  retrieval/       SearchChunks use case + ports
  shared/          EmbeddingProvider port
  observability/   JSON formatter, per-request context
  adapters/        FastAPI, OpenAI, pgvector
  main.py          composition root

Source code dependencies point inward only. A use case knows an EmbeddingProvider protocol, not OpenAI:

class EmbeddingProvider(Protocol):
    async def embed(self, texts: list[str]) -> list[list[float]]: ...

Here's the problem. The token count is only known inside the OpenAI adapter (response.usage.total_tokens). The per-request log line is written in the HTTP middleware. Between them sits the use case.

The naive fix is to make embed() return (vectors, tokens) and thread the number up through IngestDocument.execute() back to the route. That would change the port, the use case, every fake in my tests, and the use case would suddenly "know" about billing metrics. That's exactly what the dependency rule is supposed to prevent.

So I needed a side channel: something request-scoped that the adapter can write to and the middleware can read from, with the use case in the middle never noticing.

Step 1: one JSON line per event

First, logs. I stuck to the standard library and wrote a small formatter that emits JSON Lines:

class JsonFormatter(logging.Formatter):
    def format(self, record: logging.LogRecord) -> str:
        payload = {
            "ts": datetime.fromtimestamp(record.created, UTC).isoformat(),
            "level": record.levelname,
            "logger": record.name,
            "event": record.getMessage(),
            "request_id": get_request_id(),
        }
        payload.update(getattr(record, "fields", {}))
        return json.dumps(payload)

The message is an event name (request.completed, embedding.created), and structured data goes in via extra={"fields": {...}}. Any log tool can then filter by event or aggregate latency_ms without regex.

Step 2: request ID with contextvars

contextvars is the async-safe way to hold "current request" state in Python. Each request gets its own value, even when hundreds are interleaved on one event loop.

_request_id: ContextVar[str | None] = ContextVar("request_id", default=None)

def set_request_id(request_id: str) -> None:
    _request_id.set(request_id)

def get_request_id() -> str | None:
    return _request_id.get()

The middleware reuses an incoming X-Request-ID header if there is one (so once rag-service calls evorag, the same ID can follow a request across both services), otherwise it generates one, and it echoes the ID back in the response:

async def log_requests(request: Request, call_next) -> Response:
    request_id = request.headers.get("x-request-id") or uuid.uuid4().hex
    set_request_id(request_id)
    ...
    response = await call_next(request)
    response.headers["x-request-id"] = request_id

Because the formatter calls get_request_id() itself, every log line from anywhere in the app gets the ID automatically. No logger needs to be passed around.

Step 3: token counting — and why it's not a ContextVar[int]

The obvious approach for tokens would be the same pattern as the request ID: a ContextVar[int], reset to 0 in the middleware, incremented in the adapter with .set(current + tokens), read back in the middleware after call_next.

That looks right, but it doesn't work. A minimal reproduction:

counter: ContextVar[int] = ContextVar("c", default=0)
holder: ContextVar[dict | None] = ContextVar("h", default=None)

@app.middleware("http")
async def mw(request, call_next):
    counter.set(0)
    h = {"n": 0}
    holder.set(h)
    response = await call_next(request)
    print(counter.get(), h["n"])
    return response

@app.get("/x")
async def x():
    counter.set(counter.get() + 42)
    holder.get()["n"] += 42
    return {}

Output:

0 42

The int version reads back 0. The object version reads back 42.

Why: @app.middleware("http") is Starlette's BaseHTTPMiddleware, and call_next runs the rest of the app in a separate task. A new task gets a copy of the current context. The endpoint can read everything the middleware set (that's why the request ID works), but a .set() inside the endpoint only changes the copy. The middleware never sees it.

What does cross the boundary is a mutable object. The copied context still points to the same object, so mutating it in place is visible on both sides.

So the fix is to store a small holder object in the ContextVar and mutate it, never re-set it:

@dataclass
class RequestMetrics:
    embedding_tokens: int = 0

_metrics: ContextVar[RequestMetrics | None] = ContextVar("metrics", default=None)

def start_metrics() -> RequestMetrics:
    metrics = RequestMetrics()
    _metrics.set(metrics)
    return metrics

def add_embedding_tokens(tokens: int) -> None:
    metrics = _metrics.get()
    if metrics is None:   # e.g. called outside a request (scripts, tests)
        return
    metrics.embedding_tokens += tokens

The middleware creates the holder before call_next and keeps a reference to it:

    metrics = start_metrics()
    started = time.perf_counter()
    response = await call_next(request)
    latency_ms = round((time.perf_counter() - started) * 1000, 2)

    logger.info("request.completed", extra={"fields": {
        "method": request.method,
        "path": request.url.path,
        "status": response.status_code,
        "latency_ms": latency_ms,
        "embedding_tokens": metrics.embedding_tokens,
    }})

And the OpenAI adapter, the only place that knows about tokens, reports them:

        started = time.perf_counter()
        response = await self._client.embeddings.create(...)
        latency_ms = round((time.perf_counter() - started) * 1000, 2)

        tokens = response.usage.total_tokens
        add_embedding_tokens(tokens)
        logger.info("embedding.created", extra={"fields": {
            "model": self._model,
            "inputs": len(texts),
            "tokens": tokens,
            "latency_ms": latency_ms,
        }})

The EmbeddingProvider port didn't change. IngestDocument and SearchChunks didn't change. The test fakes didn't change. Observability lives entirely in the outer ring: the HTTP adapter and the OpenAI adapter, both talking to a small observability module.

What the logs showed

One POST /documents now produces two lines (some fields trimmed):

{"event": "embedding.created", "request_id": "2a2c1c38...", "model": "text-embedding-3-small", "inputs": 1, "tokens": 18, "latency_ms": 390.19}
{"event": "request.completed", "request_id": "2a2c1c38...", "method": "POST", "path": "/documents", "status": 201, "latency_ms": 439.52, "embedding_tokens": 18}

Measuring the OpenAI call separately from the whole request turned out to be the most useful part. In my early measurements the embedding call took 89–97% of total request time, while evorag's own work (chunking, DB write, serialization) stayed around 50 ms.

That changes what I'll work on next. Optimizing my own code is pointless right now; the real levers are around the external call: timeouts, retries, and moving ingestion off the request path (a RabbitMQ consumer is on the roadmap).

Testing it

The observability tests use a tiny FastAPI app with the real middleware and a fake endpoint, so no database or API key is needed:

def make_app():
    app = FastAPI()
    app.middleware("http")(log_requests)

    @app.get("/fake")
    async def fake():
        add_embedding_tokens(30)
        add_embedding_tokens(12)
        return {"ok": "yes"}

    return app

def test_middleware_sums_embedding_tokens(caplog):
    caplog.set_level(logging.INFO, logger="evorag")
    TestClient(make_app()).get("/fake")

    [record] = [r for r in caplog.records if r.getMessage() == "request.completed"]
    assert record.fields["embedding_tokens"] == 42

This test is also a regression guard for the trap above: if someone "simplifies" RequestMetrics back into a plain ContextVar[int], it fails with 0 != 42.

Other tests cover generating a request ID, reusing an incoming X-Request-ID, and the formatter with and without extra fields.

Takeaways

• Clean Architecture makes cross-cutting concerns a design question, not an afterthought. "Where does this number get produced, and where is it consumed?" decided the whole solution.

• contextvars is the right tool for request-scoped data in async Python, but values set in a child task don't flow back to the parent. If you need to collect data, store a mutable holder.

• Measure external calls separately. One extra latency_ms field told me more about where to spend effort than any amount of profiling my own code would have.

• The standard library is enough to start. No logging framework, no tracing stack yet; JSON Lines on stdout can be picked up by any tool later.

Next up for evorag: timeouts and retries around the OpenAI calls, a RabbitMQ consumer for asynchronous ingestion, and a small evaluation set to calibrate chunk size and the similarity threshold properly.

The code is on GitHub: YusufOztoprak/evorag

Retrieval-Augmented Generation (RAG) fixes this by giving the model real, relevant context to work with before it answers.

I recently built a RAG service from scratch using NestJS, PostgreSQL with the pgvector extension, and OpenAI's APIs. Here's how it works, and what I learned along the way.

Architecture Overview

The service is built with a layered NestJS architecture, split into focused modules:

database — PostgreSQL connection and pgvector setup

embeddings — chunking documents and generating vectors via OpenAI

documents — ingesting and storing source documents

query — handling incoming questions and returning grounded answers

llm — prompting the model with retrieved context

Each module has a single responsibility, which made the system easy to reason about and test independently.

Chunking and Embedding

Before a document can be searched semantically, it has to be split into smaller pieces — chunks — and each chunk needs its own vector representation.

I chunk documents into overlapping pieces rather than clean, non-overlapping blocks. Without overlap, a chunk boundary can land in the middle of a sentence, splitting its meaning across two chunks that are each embedded independently — neither one captures the full idea. A small overlap (a few hundred characters) means that sentence near a boundary is likely to appear whole in at least one chunk.

Each chunk is embedded using OpenAI's text-embedding-3-small model and stored in PostgreSQL as a vector, using the pgvector extension. Rather than sending one API request per chunk, I batch multiple chunks into a single embeddings request — the API returns vectors in the same order as the input, so mapping each result back to its chunk is straightforward and reliable.

Retrieval

When a question comes in, it's embedded using the same model, then compared against every stored chunk using cosine distance — a measure of how close two vectors are in meaning, not just in wording.

This comparison happens inside PostgreSQL itself, via pgvector's distance operator, rather than pulling every chunk into the application and comparing them in code. For a handful of chunks the difference is negligible, but it matters enormously at scale: computing distances in the database avoids transferring thousands of large vectors over the network, and lets a highly optimized engine do the sorting instead of a slow loop in application code.

The closest matches are passed to the LLM as context, and the model is prompted to answer using only that context — which is what keeps the answers grounded instead of hallucinated.

What I Learned

A few things stood out while building this:

Chunking strategy matters more than it seems at first. It's tempting to treat it as a trivial preprocessing step, but the boundaries you choose directly affect retrieval quality later on.

Most of the real debugging wasn't in the AI logic — it was in the surrounding infrastructure: container port conflicts, environment variable caching, and making sure async code actually awaits what it needs to. RAG systems are, underneath the AI layer, still ordinary backend systems that need to be built carefully.

One bug stuck with me: a SQL statement silently broke because a Turkish "ı" (dotless i) had slipped into an uppercase SQL keyword through my keyboard's autocomplete — PostgreSQL rejected it as invalid syntax, and the error message alone didn't make the cause obvious. Small reminder that "write code in English" isn't just a style preference.

Grounding matters. An LLM given the right context produces noticeably more reliable answers than one relying on its training data alone.

What's Next

I'm currently building a second RAG service, this time in Python with FastAPI, async SQLAlchemy, and pgvector, focused on scientific literature. It's a chance to rebuild the same core ideas in a different stack and see what changes. I'll be writing about that next.