DEV Community: Peace Melodi

[Boost]

Peace Melodi — Tue, 11 Aug 2026 00:33:54 +0000

Peace Melodi

Aug 11

What Really Happens Between a Request and a Response in NestJS

#nestjs #node #javascript #typescript

2 min read

[Boost]

Peace Melodi — Tue, 11 Aug 2026 00:05:12 +0000

Peace Melodi

Aug 10

Why I Chose NestJS and Never Looked Back

#nestjs #node #typescript #javascript

2 min read

What Really Happens Between a Request and a Response in NestJS

Peace Melodi — Tue, 11 Aug 2026 00:02:31 +0000

Have you ever wondered what actually happens in the few seconds between clicking a button on a website and seeing something appear on your screen? It feels instant, almost like magic. But there is a real journey happening behind that moment, and once you understand it, a lot of what feels confusing about NestJS starts to make sense.

Think about how a letter travels through the mail. It gets picked up, sorted, checked to make sure it is addressed correctly, handled by the right person, and eventually delivered, with a reply sometimes making its way back to you. Every step exists for a reason, even though you never see most of it happen.

Something similar happens every time you ask an app to do something, even something as small as clicking a button to log in. That click is really you asking the app a question, and what appears afterward is really its answer coming back to you. NestJS is the system responsible for guiding that journey properly, from your ask all the way to the answer.

Your ask first reaches a part of the app whose only job is to receive it and send it to the right place, like a mail carrier delivering a letter to the correct department. From there, it is often checked to make sure it is allowed to proceed, much like a letter being confirmed safe before it goes further inside. Once it clears that check, it reaches the part that does the real work, quietly preparing an answer behind the scenes. And finally, that answer makes its way back out to you, showing up simply as something appearing on your screen.

In case you are curious what developers call these two moments, your ask is called a request, and the answer coming back is called a response. That is really all those two words mean, your question going in, and the answer coming back out.

Here is the lesson worth taking from this, even outside of code. Anything that feels instant on the surface usually has quiet, careful steps happening underneath it, steps that exist to keep things organized and safe, not to slow things down. The more clearly each step knows its one job, the smoother the whole journey becomes.

You do not need to memorize any technical terms today. You only need to know that every ask you send an app goes on a real journey before an answer comes back. Next time something loads instantly, you can smile a little, knowing there was a quiet, organized journey happening behind that speed.

I write these thoughts as Peace Melodi, a backend software engineer who cares deeply about building things that hold up under real pressure, real users, and real growth. If any of this resonated with you, I would love to connect.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

You Can Actually Understand NestJS, Here Is Where to Start

Peace Melodi — Mon, 10 Aug 2026 22:56:51 +0000

If you have ever opened a NestJS project for the first time and felt a small wave of panic looking at all the folders and unfamiliar words on your screen, that feeling does not mean you are behind. It just means you are looking at order you do not understand yet, and that fades faster than you think.

Here is the one idea to hold onto before anything else. NestJS exists because growing projects naturally turn messy if nothing holds them together, so it gives every piece of your app a clear, dedicated place to live instead of letting everything pile up in one tangled mess.

Think of a NestJS project like a well organized house. A module is like a room in that house, a kitchen, a bedroom, a living room, each one holding the things that belong together instead of everything being scattered across the floor. A controller is like the front door, it is the part that answers when someone knocks, listens to what they want, and decides where inside the house they need to go. A service is like the kitchen, it is where the real work actually happens, quietly, behind the scenes, after the front door has let the request in. And a guard is like the lock on the door, it checks whether the person knocking is even allowed inside before anything else is allowed to happen.

You do not need to memorize any of this today. You just need to know these four pieces exist, and that each one has its own clear job instead of everything doing everything.

So here is where I actually want you to start. The next time you open a NestJS project, do not try to understand everything at once. Just look for these four things, a room that groups things together, a door that receives requests, a kitchen where the real work happens, and a lock that protects access. That is it. That is enough for today.

You do not need to feel ready to master NestJS right now. You only need to start noticing the order that is already there, and trust that understanding follows people who pay attention, not people who rush.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

Why I Chose NestJS and Never Looked Back

Peace Melodi — Mon, 10 Aug 2026 21:19:04 +0000

A few years ago, I was just another developer trying to figure out how to build things that actually work, not just things that run once and fall apart the moment real users touch them. I tried a few paths. I read a lot. I broke a lot of things. And somewhere along that road, I found NestJS.

At first, it looked like just another tool. Another framework to learn, another thing to add to my resume. But the more I used it, the more I realized something. NestJS wasn't just teaching me how to build backend systems. It was teaching me how to think like someone who builds things meant to last.

I did not choose NestJS because it was trendy. I chose it because it made me feel organized in a way nothing else had. It gave structure to ideas that used to feel messy in my head. It made me feel like a professional, not just someone typing code and hoping it works.

Here is the lesson I want you to take from this, even if you never write a single line of NestJS code. Anything you build, whether it is software, a business, or even your own life, lasts longer when it has structure. Not rules for the sake of rules, but structure that makes room for growth without everything falling apart. That is what NestJS taught me first, before it taught me anything technical. Organize your thinking, and the work becomes easier to carry.

Today, when people ask me why I still use NestJS after all this time, my answer is simple. It is not just a tool I use. It is the reason I became confident in what I do. And once you experience that kind of confidence in your work, it is very hard to walk away from it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

I Created a NestJS Delivery Dispatch Backend with Concurrency Control & Dockerized Postgres

Peace Melodi — Sat, 08 Aug 2026 13:51:53 +0000

I built this delivery dispatch service to practice and master core backend engineering fundamentals in NestJS. Instead of just building a basic CRUD API, I wanted to understand how real-world dispatch systems manage state transitions, handle route assignments, and keep data consistent under concurrent requests.

The backend is engineered with NestJS, TypeORM, and PostgreSQL running inside Docker containers. To handle state protection, I implemented concurrency guards that intercept duplicate route acceptance requests and immediately throw an HTTP 409 Conflict exception before any invalid state mutation reaches the database.

To streamline my testing workflow without manually dropping database schemas, I also built a Node.js automation script (scripts/clear-db.js) that pipes dynamic SQL queries straight into the Docker container via IPC streams.

In the video, I walk through the route acceptance logic, demonstrate how the HTTP 409 conflict guard blocks duplicate claims, and run a live demo of the automated database reset in action.

Check out the video below to watch the full walkthrough in action. If you enjoy the demo, please give the video a like and leave a comment with your thoughts!

How a Double Entry Ledger Works, Built From Scratch in NestJS

Peace Melodi — Fri, 07 Aug 2026 17:06:20 +0000

I built Parity Ledger to solve a problem most backend systems ignore. Most systems track money with a single balance column, a number sits on an account record, it goes up when money comes in, it goes down when money goes out. That works fine until two requests hit the same account at the same time, or until someone needs to know what actually happened to an account months later and there is nothing but today's number staring back.

Parity Ledger is a double entry bookkeeping engine built with NestJS and Postgres. Instead of storing a balance, every movement of money is written as a permanent, immutable entry. Nothing gets updated, nothing gets deleted. Every transaction writes two entries at once, a debit and a credit, inside a single atomic database transaction, so money can never leave one account without landing in another.

To keep things correct under real concurrent pressure, the ledger uses row level locking at the exact point where two requests could touch the same account balance at once. I built a live dashboard to actually demonstrate this, firing two transfer requests at the same account at the same moment and watching the lock force one to wait its turn.

In the video I walk through how it all works, the reasoning behind ditching the balance column, how the debit/credit pairing is enforced, and a live demo of the concurrency lock in action.

NestJS and the Discipline It Takes to Never Let a Bank's Numbers Lie to You

Peace Melodi — Fri, 24 Jul 2026 12:28:07 +0000

A number that represents money is only trustworthy if it can never quietly change without leaving a trace. That sounds obvious once it is said out loud, yet it is one of the easiest rules to break by accident. A support agent fixes a customer's balance directly in the database after a complaint. A backend job updates an account total to correct a bug. A well meaning developer runs a one off script to patch a number that looked wrong. Every one of these actions feels reasonable in the moment, and every one of them destroys the one thing a financial system actually depends on, the ability to prove, later, exactly how a number became what it is.

This is the real discipline behind a trustworthy financial backend, and it has very little to do with clever code and everything to do with refusing to ever let a balance be edited directly. It is also one of the least glamorous parts of building financial software, which is exactly why it gets skipped so often. Nobody sets out to build a system that lies about money. It happens gradually, one convenient shortcut at a time, until the system has quietly drifted into a place where nobody can fully explain how a number got to be what it is.

Why a stored balance cannot be the source of truth

Most systems that are not built with this discipline store an account balance as a single number and update it in place whenever money moves. The moment that number can be changed directly, by a script, an admin panel, or a rushed bug fix, it stops being a fact and becomes an opinion, something that reflects whatever the last write happened to be, with no way to reconstruct how it got there. If a customer disputes their balance six months from now, or a regulator asks how a number was reached, a system built this way has no real answer beyond trusting that everything along the way was done correctly.

This is not a hypothetical concern. Financial disputes are common, regulators do ask these questions, and the answer a bank gives in that moment either comes from a system that can reconstruct its own history with certainty, or from a system that is essentially asking everyone to take its word for it.

Treating every change as a new fact, never an edit

The discipline that fixes this is refusing to ever update a balance directly. Instead, every single change to an account is recorded as its own permanent entry, and the balance itself is only ever calculated by adding up every entry that has ever happened. Nothing is ever overwritten. A correction is not an edit to history, it is a new entry that says exactly what was corrected and why, sitting right alongside everything that came before it.

In NestJS, this discipline lives naturally inside the service layer, where a balance is never something you fetch and mutate, it is something you compute fresh, every time, from the full history of entries tied to that account. The service becomes the one place this rule is actually enforced, rather than something every developer has to remember on their own.

async getAccountBalance(accountId: string): Promise<string> {
  const result = await this.dataSource
    .createQueryBuilder()
    .select(
      "SUM(CASE WHEN entry.type = 'CREDIT' THEN entry.amount ELSE -entry.amount END)",
      'balance',
    )
    .from(LedgerEntry, 'entry')
    .where('entry.accountId = :accountId', { accountId })
    .getRawOne();

  return result?.balance ?? '0.0000';
}

There is no balance column being read here, and nothing being written to correct one either. The number is simply the honest sum of everything that has ever happened to that account, which means it cannot drift away from reality without every single entry behind it also being wrong.

What happens when a mistake genuinely needs fixing

This discipline does not mean mistakes never get corrected, they absolutely do. What changes is how a correction is made. Instead of reaching into the database and changing an existing entry, a correction is made by adding a brand new entry that reverses or adjusts the original one, clearly labeled as a correction, tied back to whatever it is fixing. If a customer was charged the wrong amount, the fix is not deleting the wrong entry and quietly typing in the right number. The fix is leaving the original entry exactly as it happened, and adding a second entry beside it that corrects the balance going forward while preserving an honest record of what actually occurred, including the mistake itself.

This might feel slower or more cautious than simply editing a number, and it is, deliberately so. The extra step is what makes the difference between a system that can fully explain itself later and one that can only ever hope nobody asks.

Making it structurally hard to cheat

The other half of this discipline is making sure nothing in the system can bypass it, even under pressure. That means the database itself should never allow a ledger entry to be updated or deleted once it has been created, only ever inserted. Combined with the fact that the balance is always computed rather than stored, there is simply no direct path left for a rushed fix or a one off script to quietly rewrite history, because there is no editable number sitting anywhere to rewrite.

The actual value of this discipline

None of this is about distrusting the people who work on the system. It is about removing the need to trust anyone's good intentions in the first place. A bank does not want to be in a position where the honesty of its numbers depends on nobody ever taking a shortcut under deadline pressure. Building the discipline directly into how the backend is structured, immutable entries, computed balances, corrections instead of edits, means the numbers stay honest by default, not because everyone remembered to be careful, but because the system never gave anyone the option not to be.

If you are working on a system where the numbers need to hold up under real scrutiny, not just in a demo, I would be glad to talk through how to structure it this way from the start.

I am Peace Melodi, a backend software engineer. If you want your business to scale big, comfortably handling millions of users without breaking, with strong scalability and security in place, feel free to reach out.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

What a Bank's Payment Flow Actually Needs Underneath, and Why NestJS Was Built for Exactly That

Peace Melodi — Fri, 24 Jul 2026 10:17:16 +0000

Moving money between two accounts sounds like a small task. Take an amount from one place, add it to another, done. In reality, a payment flow that actually holds up in production has to get several things right at the same time, every single time, without exception. It has to check that the numbers are actually valid before touching anything. It has to make sure that if any part of the operation fails partway through, nothing is left in a broken, half finished state. And it has to survive the same request arriving more than once, since networks retry, users double click, and providers resend, whether anyone plans for it or not.

None of these requirements are unique to any one bank or any one payment provider. They are the same three requirements every payment system on earth has to satisfy, and they are exactly the kind of structure NestJS was designed around from the start.

Getting the validation right before anything is trusted

A payment flow cannot afford to trust the shape of incoming data. An amount that is missing, negative, or malformed has to be rejected before it ever reaches a service or touches a database. NestJS handles this through DTOs paired with a global validation pipe, so a request is checked and shaped correctly before a single line of business logic even runs.

export class TransferDto {
  @IsUUID()
  fromAccountId: string;

  @IsUUID()
  toAccountId: string;

  @IsNumberString()
  amount: string;
}

This is a small piece of code, but the value is not in the code itself, it is in where it sits. Validation happens at the edge of the system, automatically, on every single request that reaches this route, rather than depending on a developer remembering to check it manually somewhere deep inside a service.

Making sure nothing is ever left half done

The second requirement is atomicity. If a transfer touches two accounts, and something fails after the first account has already been updated, the second account cannot be left waiting forever in an inconsistent state. NestJS, through TypeORM's query runner, gives you a clean way to wrap the entire operation so it either fully succeeds or fully rolls back, with nothing in between.

The pattern is straightforward once it is in place, start a transaction, perform every write that belongs to that one operation, and either commit everything together or roll everything back together the moment anything goes wrong. What matters is that this pattern lives in one place, structured the same way every time a transfer happens, instead of being reinvented, or forgotten, in every new feature that touches money.

Surviving a request that arrives more than once

The third requirement is the one most systems get wrong first. A slow network, a retried request, a user clicking twice, all of these can cause the exact same payment instruction to arrive at the backend more than once. Without protection, that means the same transfer gets executed twice. NestJS gives you a natural place to check for this, a guard or an interceptor sitting in front of the actual transfer logic, checking an idempotency key against previous requests before anything is allowed to proceed a second time.

@Injectable()
export class IdempotencyGuard implements CanActivate {
  constructor(private readonly idempotencyService: IdempotencyService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const key = request.headers['idempotency-key'];

    return !(await this.idempotencyService.wasAlreadyProcessed(key));
  }
}

Once this sits in front of a route, a duplicate request simply stops before it can do any damage, without the rest of the payment logic needing to know or care that it almost ran twice.

Why NestJS fits this so naturally

None of these three requirements are ideas NestJS invented. Validation, atomic operations, and duplicate protection are basic requirements of any serious payment system, in any language, on any framework. What NestJS actually offers is a clear, consistent place to put each one, a pipe for validation, a guard for duplicate protection, a service layer for the atomic transaction itself, so a team of developers all end up enforcing the same discipline the same way, instead of every new payment feature reinventing these protections from memory and inevitably forgetting one of them under a deadline.

That consistency is the real reason NestJS keeps showing up underneath serious financial backends. Not because it is the only framework capable of handling money safely, but because its structure makes the safe way also the easy way to build it.

If your team is building or reworking a payment flow and wants that discipline built in from the start rather than patched in after something goes wrong, I would be glad to talk through it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

The Quiet Risk in How Most Banks Store Customer Documents, and How NestJS Handles It Properly

Peace Melodi — Thu, 23 Jul 2026 22:08:50 +0000

A compliance officer at a bank was preparing for an upcoming audit when she asked a question nobody on the engineering team had a clean answer to. Every customer who opened an account had uploaded a government ID and a proof of address. Where exactly were those files sitting, who could actually open them, and could the bank prove that. The honest answer was uncomfortable. The files were sitting in a storage bucket, reachable by a plain public link, generated once at upload time and never expiring. Anyone who ever got hold of one of those links, through a shared screenshot, a browser history, a support ticket, could open a customer's ID months or years later. Nothing had leaked yet. But nobody could say with any confidence that it never would.

This is not a rare mistake. It is what happens by default when file upload is treated as a simple feature instead of something that needs the same discipline as handling money itself.

Why this risk hides so well

Uploading a document and storing a link to it works, in the sense that the feature functions and nobody notices a problem in testing. The risk is invisible until the exact moment it is not, a leaked link, a support agent who should never have seen a customer's ID, a storage bucket accidentally left open to the public. By the time it is noticed, the damage is already done, and for a bank, a document like a government ID or a bank statement is not something you get to quietly walk back.

Never storing documents with a permanent public link

The first fix is making sure a document is never reachable through a link that lasts forever. Instead of a public URL, the file should sit in private storage, and access should only be granted through a short lived, signed link generated on demand.

import { Injectable } from '@nestjs/common';
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

@Injectable()
export class DocumentAccessService {
  private readonly s3Client = new S3Client({ region: 'us-east-1' });

  async generateAccessUrl(bucket: string, key: string): Promise<string> {
    const command = new GetObjectCommand({ Bucket: bucket, Key: key });

    return getSignedUrl(this.s3Client, command, { expiresIn: 300 });
  }
}

A link like this stops working after a few minutes. If it ever leaks, whoever finds it has already missed the window to use it.

Enforcing who is allowed to even ask for a document

Generating a short lived link is only half the fix. The endpoint that generates it has to strictly confirm the requester is actually allowed to see that specific document, not just that they are logged in.

import { Injectable, CanActivate, ExecutionContext, ForbiddenException } from '@nestjs/common';

@Injectable()
export class DocumentOwnershipGuard implements CanActivate {
  constructor(private readonly documentsService: DocumentsService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const requestingUserId = request.user.id;
    const documentId = request.params.documentId;

    const document = await this.documentsService.findById(documentId);

    if (!document || document.ownerId !== requestingUserId) {
      throw new ForbiddenException('You do not have access to this document');
    }

    return true;
  }
}

This guard sits in front of the route, so nobody, including a support agent using their own account, can pull up a document that does not belong to the customer they are actually assisting, unless that access is explicitly modeled and permitted.

Recording every time a document is accessed

The compliance officer's real question was whether the bank could prove who accessed a document and when. That means every single access needs to be logged, not just allowed or denied.

import { Entity, Column, PrimaryGeneratedColumn, CreateDateColumn } from 'typeorm';

@Entity('document_access_logs')
export class DocumentAccessLog {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  documentId: string;

  @Column()
  accessedByUserId: string;

  @Column()
  reason: string;

  @CreateDateColumn()
  accessedAt: Date;
}

With this in place, an audit question like who looked at this customer's ID and why becomes something the bank can answer with a query, not a guess.

The bigger picture

NestJS does not know anything about compliance requirements on its own. What it gives you is a place to put each layer of this properly, a service that only ever issues short lived signed access instead of permanent links, a guard that checks real ownership before anything is generated, and a log that records every access without exception. None of these pieces are complicated individually. What matters is that the structure makes it hard to skip any of them under deadline pressure, since that is usually how a customer's sensitive documents end up sitting behind a link that never expires in the first place.

If your team is storing anything sensitive, documents, IDs, statements, and you are not fully sure who could actually access them today, I would be glad to talk through how to tighten that up.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

A Bank Wanted to Use AI to Approve Loans Faster, Here Is What I Would Build Around It in NestJS

Peace Melodi — Thu, 23 Jul 2026 21:44:33 +0000

A loan officer at a small digital bank was excited about the new model the data team had built. It could score a loan application in under a second, based on income, spending patterns, and repayment history, and approve or reject it automatically. The first week it ran, it worked beautifully. The second week, the model provider had an outage in the middle of the afternoon. Every loan application submitted during that window just hung, waiting on a response that was never coming. Some customers refreshed the page and submitted twice. A few applications that should have been rejected outright ended up approved, because a fallback path someone had written months earlier, and never tested properly, defaulted to approving anything it could not score.

Nobody on the data team had done anything wrong with the model itself. The model was accurate. What was missing was everything around it, the part that decides what happens when the model is slow, wrong, unavailable, or simply not something you should trust blindly with a decision this big.

The real problem is never the model

A bank does not really have an AI problem when it adopts a model for something like loan approval or fraud scoring. It has an integration problem. The model is a service you call, and like any service, it can be slow, it can fail, and it can be confidently wrong. The question that matters is not whether the model is smart. It is what the backend does the moment the model does not behave the way everyone assumed it would.

Enforcing a timeout so a slow model cannot freeze the whole flow

The first guardrail is making sure a call to the model can never hang indefinitely. If the model provider is slow or down, the request should fail fast and fall back to a safe default, not leave the customer staring at a loading screen.

import { Injectable, HttpException, HttpStatus } from '@nestjs/common';
import { HttpService } from '@nestjs/axios';
import { firstValueFrom, timeout, catchError } from 'rxjs';

@Injectable()
export class LoanScoringService {
  constructor(private readonly httpService: HttpService) {}

  async scoreApplication(applicationId: string, payload: Record<string, unknown>) {
    return firstValueFrom(
      this.httpService.post('https://ai-provider.example.com/score', payload).pipe(
        timeout(2000),
        catchError(() => {
          throw new HttpException(
            'Scoring service unavailable',
            HttpStatus.SERVICE_UNAVAILABLE,
          );
        }),
      ),
    );
  }
}

Notice that the fallback here is an explicit error, not a silent approval. Whatever happens next, defaulting to approving a loan because a service call failed is never an acceptable behavior on its own.

Deciding what fail safe actually means for a loan decision

Once a timeout or failure is caught, something has to happen next, and for a decision this significant, that something should never be an automatic approval. A sensible fail safe path is to route the application to a manual review queue instead.

async handleScoringFailure(applicationId: string) {
  await this.reviewQueueService.enqueue({
    applicationId,
    reason: 'scoring_service_unavailable',
    requiresManualReview: true,
  });

  return {
    status: 'pending_review',
    message: 'Your application is being reviewed manually.',
  };
}

This keeps the customer informed honestly, and it makes sure a technical failure never quietly turns into a financial decision nobody actually made on purpose.

Logging every decision so it can be explained later

A bank will eventually need to explain why a specific customer was approved, rejected, or flagged, sometimes months later, sometimes to a regulator. That means every scoring decision, along with the model's output and the data it was based on, needs to be recorded, not just acted on and discarded.

import { Entity, Column, PrimaryGeneratedColumn, CreateDateColumn } from 'typeorm';

@Entity('loan_decisions')
export class LoanDecision {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  applicationId: string;

  @Column({ type: 'jsonb' })
  modelInput: Record<string, unknown>;

  @Column({ type: 'jsonb' })
  modelOutput: Record<string, unknown>;

  @Column()
  finalDecision: string;

  @Column({ default: false })
  requiredManualReview: boolean;

  @CreateDateColumn()
  createdAt: Date;
}

With this in place, a decision made in under a second can still be fully reconstructed and explained later, which matters far more in banking than in almost any other kind of application.

Keeping a human in the loop for the decisions that matter most

Not every decision needs a person reviewing it, but the ones with real consequences, a large loan amount, a borderline score, a customer disputing a rejection, should never be finalized by the model alone. NestJS gives you a clean place to enforce that gate, a check that routes certain outcomes to a review queue instead of directly to the customer, based on rules the bank actually agrees with, rather than whatever the model happened to output.

The bigger picture

NestJS does not make an AI model more accurate, and it never should try to. What it gives you is the structure around the model, a place to enforce timeouts, a place to decide what fail safe actually means, a place to log every decision so it can be explained later, and a place to insist a person reviews the decisions that deserve one. That structure is what actually makes an AI model safe enough to use for something as consequential as approving a loan.

If your team is bringing AI into a process that touches real money or real customers, I would be glad to talk through how to build the guardrails around it properly.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

The First Question I Would Ask a Bank Before Using NestJS to Make Sure Their Money Is Always Accounted For

Peace Melodi — Thu, 23 Jul 2026 21:30:41 +0000

A finance officer at a mid sized bank was closing out the month when the numbers refused to line up. Customer accounts held a few cents more, in total, than the bank's own settlement records said they should. She ran the reconciliation again, certain it was her mistake. Same result. She pulled in an engineer, who spent two days going line by line through the transaction logic looking for the missing bug. There was no missing transaction. There was no attacker. There was no single line of broken code anyone could point to. The gap had been forming quietly for months, a fraction of a cent at a time, every single time interest was calculated or a fee was split between accounts.

Nobody had done anything wrong. The mistake had been made much earlier, before either of them had joined the company, in a decision about how money would be represented inside the system in the first place.

The first question I would ask

Before I would agree to use NestJS to build or touch any part of a bank's money handling, the first question I would ask is simple. How are amounts stored and calculated internally, as ordinary numbers, or as something built specifically to represent money exactly.

It sounds like a small detail. It is the single decision that determines whether the numbers can ever quietly drift apart from reality.

Why plain numbers cannot be trusted with money

JavaScript, like most languages, represents regular numbers using floating point. Floating point is excellent for scientific calculations and graphics, where being off by a tiny fraction almost never matters. It is not designed to represent decimal currency amounts exactly. A value like zero point one, which looks perfectly ordinary to a person, cannot always be stored exactly in that format. Individually, the error is too small to notice. Add, subtract, split, and multiply that number millions of times across a real banking system, and those tiny errors accumulate into amounts that are large enough to matter, and impossible to trace back to a single obvious bug.

This is exactly why the reconciliation report in the opening story slowly drifted. Nothing was ever technically wrong with the logic. The numbers themselves were never being represented with the precision the business rules assumed they had.

How NestJS keeps money precise

This is where the actual engineering discipline comes in, and it has to be enforced at every layer, not just trusted in one place.

The first layer is validation at the edge of the system, the DTO. Before an amount is even accepted, it should be validated as a properly formatted decimal string, not a loose number.

import { IsString, Matches } from 'class-validator';

export class CreateTransactionDto {
  @IsString()
  @Matches(/^\d+(\.\d{1,4})?$/, {
    message: 'amount must be a valid decimal string with up to four decimal places',
  })
  amount: string;
}

Accepting the amount as a string, rather than a number, means it arrives exactly as written, with no floating point conversion happening before validation even runs.

The second layer is the database schema itself. The column that stores the amount should use a fixed precision decimal type, not a floating point column, so the database itself refuses to silently round or approximate the value.

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity('ledger_entries')
export class LedgerEntry {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column({ type: 'numeric', precision: 15, scale: 4 })
  amount: string;
}

The third layer is arithmetic itself. Any place in a NestJS service where amounts are added, subtracted, or compared should never rely on plain JavaScript math on those values directly. Instead, the calculation should happen through a library built for exact decimal arithmetic, so precision is preserved through every step, not only at storage.

import Decimal from 'decimal.js';

function calculateTotal(amounts: string[]): string {
  return amounts
    .reduce((total, current) => total.plus(new Decimal(current)), new Decimal(0))
    .toFixed(4);
}

Put together, these three layers mean an amount is validated as exact the moment it enters the system, stored as exact the moment it is saved, and calculated as exact every time it is touched. There is no point in the chain where a silent rounding error can slip in.

The bigger picture

NestJS will not automatically protect a bank from this mistake. Nothing in the framework forces a developer to use decimal strings instead of plain numbers, or a fixed precision column instead of a floating point one. What NestJS gives you is a clean, enforceable place to put each of these decisions, a validation rule at the DTO layer, a column definition at the entity layer, and a consistent calculation approach at the service layer, so the whole team follows the same discipline instead of everyone reinventing it, or forgetting it, feature by feature.

If your team is dealing with numbers that quietly do not add up, or you are building something from scratch and want the precision handled correctly from day one, I would be glad to talk through how to structure it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi