Forem: Danilo Assis

Ship Every Day: Progress is a Puzzle Made Piece by Piece

Danilo Assis — Tue, 10 Mar 2026 12:50:33 +0000

Core Leadership Principle #3

When I was junior, I watched companies and teams measure success by big releases. The quarterly launch. The major version. The dramatic all-hands demo.

Everyone celebrated those moments. But between them? Weeks of invisible work. Teams grinding away, not shipping anything, wondering if they were making progress.

I followed that pattern early on. Work on something for weeks, ship nothing, then finally push everything at once. It felt normal. That's what I saw everywhere.

Then I joined a team that worked differently. Developers were constantly shipping. Not always full features. Sometimes just a test. Or documentation. Or a bug fix. But every single day, something tangible moved forward.

I asked one of them how they maintained that pace. His answer changed everything:

"Shipping to production is a puzzle. You can't place all the pieces at once. But you can place one piece every day. Eventually, you complete the picture."

That's when I learned: there is no day where you don't make progress.

What "Ship Every Day" Actually Means

This isn't about posting in Slack: "Here's what I did today!"

It's not a reporting requirement. It's a mindset.

Every single day, you should be able to answer three questions:

What did I ship today? (Code, test, fix, documentation, unblocked issue)
What am I improving today? (Skill, process, codebase, understanding)
What's my next piece of the puzzle? (Next concrete step)

If you can't answer these, you didn't have a productive day.

The Puzzle Mindset

Here's what changed for me: I stopped thinking in "features" and started thinking in "pieces."

Old thinking:
"I'm working on the authentication system. It'll be done in two weeks."

Then two weeks pass. Authentication isn't done. Feels like wasted time.

New thinking:

Monday: Shipped the JWT token generation logic with tests
Tuesday: Implemented token refresh flow
Wednesday: Fixed edge case with expired tokens
Thursday: Added monitoring for auth failures
Friday: Documented the auth flow for the team

Same two weeks. But now I have five concrete things I shipped. Even if "authentication system" isn't 100% done, I made real progress every single day.

What Counts as Shipping

You don't need to push to production every day. But you need to complete something tangible:

Code:

Merged a PR (even a small one)
Fixed a bug
Wrote tests for existing code
Refactored a confusing module

Not Code:

Identified root cause of a production issue and documented it
Wrote an RFC for a technical decision
Updated documentation that was wrong
Unblocked a teammate by answering their question thoroughly

Progress:

Researched an approach and ruled it out (with evidence)
Set up monitoring for a feature that didn't have it
Improved CI/CD pipeline
Created a runbook for on-call

All of these count. They all move the puzzle forward.

What Doesn't Count

"I worked on stuff today."
Too vague. What stuff? What's done now that wasn't done before?

"Still working on that feature from last week."
What part? What's complete? What's next?

If you go three days without shipping something tangible, you're stuck. Reset your approach.

The Daily Questions

Every evening, I ask myself:

1. What did I ship today?

Good answer: "I fixed the CSS bug blocking the UI team, wrote documentation for the new API endpoint, and got DBA approval for the database migration."

Bad answer: "Worked on the migration."

2. What am I improving today?

Good answer: "Learned how PostgreSQL handles concurrent updates - wrote notes on it."

Bad answer: "Read some docs."

3. What's my next piece?

Good answer: "Tomorrow I'm implementing the rollback plan for the migration."

Bad answer: "Continue working on migration stuff."

See the difference? Concrete vs. vague.

Small, Mergeable PRs

One practice that helps: keep PRs small.

Target: under 400 lines when possible.

Why? Because small PRs:

Get reviewed faster
Have fewer bugs
Are easier to understand
Can be merged daily

Instead of one massive PR with your entire feature, break it into pieces:

PR 1: Database schema changes
PR 2: API endpoints (behind feature flag)
PR 3: Frontend integration
PR 4: Tests
PR 5: Enable feature flag

Now you're shipping something every day instead of waiting two weeks to ship everything at once.

Feature Flags Are Your Friend

Here's the trick: you can ship code to production even if the feature isn't ready.

Use feature flags.

Ship the authentication module but keep it disabled. Ship the new API endpoint but don't expose it yet. Ship the UI but hide it behind a flag.

This lets you:

Deploy daily
Test in production (with the flag off)
Enable gradually when ready
Roll back instantly if needed

Shipping to production daily, even with features disabled, keeps you honest. Your code has to actually work. You can't accumulate a month of untested changes.

When I Got Stuck

I was once building a complex hospital integration. Two weeks in, I'd written a lot of code but shipped nothing to production. It "wasn't ready yet."

My manager asked: "What have you shipped this week?"

I said: "I'm still working on it."

He said: "Can you ship any piece of it?"

That question changed everything. I realized:

The data parsing logic worked - I could ship that
The validation rules were solid - I could ship those
The error handling was done - I could ship that

I broke it apart. Started merging pieces daily. Put them behind a feature flag.

Two weeks later, I flipped the flag on. Everything worked. Because I'd been shipping and testing pieces all along instead of waiting to ship one giant blob.

The Compound Effect

Here's what happens when you ship every day:

Week 1: Feels slow. Just small pieces.

Week 4: You look back and realize you shipped 20 things. Some small, some bigger. But 20 real, complete things.

Month 3: Your velocity is higher than people who work in big batches. Because you're not blocked. You're not waiting. You're always moving.

Month 6: You've become the person who "always gets things done." Not because you work harder. Because you work in smaller, continuous pieces.

This Isn't Micromanagement

Let me be clear: this isn't about reporting to anyone.

Nobody needs to know what you shipped today. This is for you.

It's a way of working that keeps you honest and moving forward.

Some days you'll ship a massive feature. Some days you'll ship one bug fix. Both are fine.

The point is: no day ends with "I just worked on stuff."

The Test

Tonight, before you stop working, answer:

What did I ship today?
What did I improve?
What's my next piece?

If you can't answer, you're drifting. Reset tomorrow.

If you can answer all three, you had a productive day. Do it again tomorrow.

String together enough of those days, and you'll ship more than you ever thought possible.

Start Tomorrow

Pick the thing you're working on right now.

Ask yourself: "What one piece of this can I finish and ship tomorrow?"

Not the whole thing. One piece.

Then ship it.

The next day, ship the next piece.

That's how you build software. That's how you make progress.

One piece of the puzzle at a time.

This is part 3 of a 14-part series on Core Leadership Principles. Next week: AI as Assistant, Not Autopilot - how to use AI without outsourcing your thinking.

How do you track daily progress? What helps you maintain momentum when working on long projects?

Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.

Photo by Tanja Tepavac on Unsplash

Ownership & Accountability: You Own Your Code from Concept to Production

Danilo Assis — Thu, 19 Feb 2026 12:22:14 +0000

Core Leadership Principle #2

It was 2 AM. Production was down. The team was scrambling in Slack trying to figure out what broke.

Someone deployed a feature that afternoon. Everything looked fine in staging. But in production, it was causing a cascade of failures across our integrations.

The developer who wrote it? Offline. Asleep. Had no monitoring set up. No alerts configured. No documentation about how the feature worked or what could go wrong.

We spent four hours debugging someone else's code, in the dark, with real users unable to process data.

That's when I learned what ownership actually means.

What Ownership Looks Like

Ownership isn't just writing code. It's owning that code from the moment you have the idea until it's retired from production.

That means:

You understand the problem you're solving
You design the solution
You write the code
You test it
You deploy it
You monitor it
You fix it when it breaks
You improve it over time

If you write code and throw it over the wall for someone else to deal with, you're not owning anything. You're just coding.

The Two-Hour Rule

Here's a pattern I see all the time:

Developer hits a bug. Stares at it for six hours. Finally asks for help at 5 PM: "Hey, this isn't working, can you take a look?"

Six hours of being stuck. Zero communication.

Better approach: If you're blocked for more than 2 hours, raise it.

But here's the key - don't just say "it's broken, help me." Show what you tried:

"I'm stuck on this auth bug. I've tried:

Checking JWT token expiration - tokens are valid
Validating signature algorithm - matches what we configured
Using Claude to review the middleware - found nothing
Here are my logs [paste]

I think it's in the token refresh flow, but I need another set of eyes."

See the difference? You did the work. You exhausted your options. You documented what you tried. You have a theory about where the problem is.

Now when someone helps you, they can actually help - not spend an hour reproducing what you should have already done.

Before You Ask for Help

Use everything available to you first:

Read the documentation
Use AI tools (Claude, ChatGPT, Gemini, Cursor)
Write failing tests that show exactly what's broken
Check similar issues in the codebase
Google the error message

If you've done all this and you're still stuck after 2 hours - perfect. Ask for help. Just show what you tried.

"Can you help?" without context is not taking ownership. It's asking someone else to own your problem.

When Things Break in Production

This is where ownership really shows.

Bad ownership:
"The deployment failed. Someone should look at it."

Good ownership:
"The deployment failed. I own it. Root cause: database migration timed out because I didn't account for the table size. I'm rolling back now. Fix: breaking the migration into smaller batches. Should be ready to redeploy in 30 minutes. Here's how we prevent this next time..."

Notice:

Takes responsibility immediately
Explains what went wrong
Has a fix plan
Knows how to prevent it
Gives timeline

That's ownership.

Setting Up for Success

When you ship a feature, you should have:

Monitoring:

Metrics tracking the important stuff (latency, errors, throughput)
Dashboards showing health at a glance
Logs that actually help you debug

Alerts:

Configured before you ship
With context - not just "something broke"
Routed to the right people

Documentation:

How does this work?
What can go wrong?
How do you fix common issues?
Who built this and how do you reach them?

If your feature goes down at 3 AM and someone else is on-call, they should be able to:

Understand what broke from the alert
Find your runbook
Fix it or know how to reach you

If they can't, you didn't finish shipping.

The Deployment That Failed

A dev once deployed a payment refactor. It tested thoroughly. Everything worked in staging. It pushed to production Friday afternoon.

Saturday morning: alerts firing. Payment processing slowed to a crawl. Users couldn't complete transactions.

The old dev might have said "worked fine in staging" and waited for someone else to investigate.

Instead:

It jumped on immediately
It found the issue: hadn't tested with production data volume
It rolled back in 10 minutes
It wrote a post-mortem
It fixed the actual issue
It added load testing to our CI/CD
It redeployed Monday with confidence

That's ownership. Not "it worked on my machine." Not "not my problem on weekends." Just: I own this, I'll fix it, here's how we prevent it.

Ownership Makes You Better

Here's what surprised me: taking full ownership made me a better engineer faster.

Why? Because when you know you're responsible for something in production, you:

Think through edge cases
Write better tests
Set up proper monitoring
Document your decisions
Care about performance
Plan for failure

You can't just write code and move on. You have to think about the whole lifecycle.

This makes you better at every part of engineering.

The Junior Developer Who Got It

I had a junior developer on my team. First significant feature. He was nervous about deploying.

But he did everything right:

Wrote comprehensive tests
Set up monitoring and alerts
Created a runbook
Deployed behind a feature flag
Watched metrics for the first hour
Posted an update in Slack

The feature worked perfectly. But more importantly, he owned it completely. When a question came up two weeks later, he knew exactly how it worked and why we built it that way.

That's the mindset. Not "I wrote some code." But "I own this feature."

Start Small

Pick one thing you're working on right now. Before you ship it:

Set up basic monitoring
Add one alert for the most critical failure mode
Write a simple runbook: "If X breaks, here's how to fix it"
Document your reasoning: "Why we built it this way"
Tell your team: "I'm shipping X, here's what to watch for"

That's ownership.

Do this consistently, and you'll notice: people trust your work more. You grow faster. Your code gets better.

Not because you're perfect. Because you own the whole thing, not just the code.

The Real Test

Next time something you built has an issue, watch your first reaction.

Is it: "Well, it worked in my environment"?
Or is it: "I'll look into that right now"?

Is it: "Someone should probably fix that"?
Or is it: "I'm on it, here's my plan"?

The difference between those reactions is the difference between a code writer and an engineer who ships.

Choose the second one. Every time.

That's ownership.

This is part 2 of a 14-part series on Core Leadership Principles. Next week: Ship Every Day - why making progress daily beats bursts of heroic effort.

How do you practice ownership in your work? What's helped you take full responsibility for your code in production?

Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.

Photo by Miguel A Amutio on Unsplash

Core Leadership Principles: A 14-Part Series on Building Better Engineering Teams

Danilo Assis — Sat, 14 Feb 2026 16:46:21 +0000

Over the next 14 posts, I'm sharing the leadership principles I've developed while building and leading engineering teams in my career. These aren't academic theories. They're battle-tested principles that emerged from real problems: missed deadlines, broken production systems, developers who couldn't grow, and teams that couldn't ship.

Here's what this series is not:

A management framework you must follow
A comprehensive guide to leadership
The "right" way to do things

Here's what it is:

14 principles I believe make engineers better
Concrete examples of what works and what doesn't
Practical actions you can take today

You won't agree with everything. You might not agree with anything. That's fine. This is about you, not me. Take what's useful. Ignore the rest. Use AI to summarize it, text-to-speech to listen while you commute, or just skim for the bold text.

What matters is this: How much do you want to get better at what you do?

The 14 Principles

Intellectual Honesty - Always have a defensible theory for why you're building something
Ownership & Accountability - You own your code from concept to production
Ship Every Day - Progress is a puzzle made piece by piece
AI as Assistant, Not Autopilot - Use AI to accelerate learning, not replace thinking
Come Prepared - Study before the class, debate during the class
Learn in Public - No DMs for technical problems
Continuous Learning - You are responsible for your own growth
Quality Without Paralysis - Ship safely, but ship
Open Discourse - Best idea wins, regardless of rank
Raise the Bar - Meet it, then raise it
Professional, Not Personal - Be effective, not nice
Bias for Action - Done and shipped beats perfect and theoretical
Active Observability - Shipping is just the beginning
Product Builders, Not Code Writers - Talk to stakeholders before building

Who This Is For

This series is for engineers who want to be more than just code writers. It's for people who want to:

Ship great software, not just write code
Build products that solve real problems
Grow faster in their careers
Lead teams without losing their technical edge
Work with a championship mentality

If you're comfortable where you are, this isn't for you. If you want to get better, keep reading.

The Foundation: Championship Mentality

Every principle in this series comes from one core belief: We're building a team of champions.

Champions ship. Champions improve. Champions raise the bar.

You have two paths:

Path A: Be comfortable, be safe, be forgettable
Path B: Be the professional who delivers, who raises the bar, who ships great work

This series is for people who choose Path B.

How to Use This Series

Each post focuses on one principle with:

The problem - why this matters
What good looks like - concrete examples
What bad looks like - what to avoid
How to practice it - actionable steps
The test - how to know if you're doing it

Read them in order. Read them out of order. Read one and stop. Come back in six months. Whatever works for you.

The only thing I ask: If you read it, apply it. Don't just collect knowledge. Use it. Test it. See if it makes you better. Come back and let's discuss what didn't work, what worked, let's improve the next version.

Let's Start

The first principle is Intellectual Honesty - the foundation of everything else. Because if you can't be honest about what you know and don't know, you can't learn, you can't grow, and you can't build anything great.

Let's go.

This is the introduction to a 14-part series on Core Leadership Principles for engineering teams. Next up: Intellectual Honesty - The Foundation of Great Engineering.

Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.

Photo by TheMarketingHustle.com on Unsplash

Intellectual Honesty - The Foundation of Great Engineering

Danilo Assis — Sat, 14 Feb 2026 16:46:11 +0000

Core Leadership Principle #1

The Problem

You're in a technical meeting. Someone asks why you chose MongoDB over PostgreSQL for the new feature. You freeze. The truth? You picked it because a tutorial you followed used it. Or because it seemed "more modern." Or because you didn't want to deal with schema migrations.

But you can't say that. So you mumble something about "scalability" and "flexibility" and hope no one asks follow-up questions.

We've all been there. And it's killing our ability to build great software.

What is Intellectual Honesty?

Intellectual honesty means you always have a defensible theory for why you're building something a certain way. Not a guess. Not a vibe. A theory you can defend with data, reasoning, or experience.

It means three things:

You know why you made a decision - not just what you decided
You're willing to change your mind - when evidence shows you're wrong
You admit what you don't know - instead of pretending

The gap between "I don't know" and "I don't know and didn't try to find out" is the difference between an honest engineer and a dangerous one.

Why This Matters

Bad Decisions Compound

That MongoDB choice? It seemed small at the time. But six months later, you're fighting with transactions, your team is debugging race conditions, and migration to PostgreSQL would take weeks. All because you picked a tool without understanding the tradeoffs.

One intellectually dishonest decision leads to another. You can't admit the database choice was wrong (because you never had a real reason for it), so you build workarounds. Then you build workarounds for the workarounds. Technical debt piles up.

Teams Can't Learn

When you pretend to have reasons you don't have, your team can't learn from your decisions. They can't evaluate the tradeoffs. They can't apply the reasoning to future problems.

Worse, you create a culture where everyone pretends. Junior developers copy your behavior. Soon, nobody knows why anything works the way it does. You're cargo culting your own codebase.

You Stop Growing

If you never admit you don't know something, you never learn it. If you never acknowledge mistakes, you never improve. Intellectual honesty is the foundation of growth.

What This Looks Like in Practice

The Good: Defendable Decisions

"I'm building this with Redis instead of our current in-memory cache because we're having latency problems under load. I've tested both approaches with 10k concurrent requests and Redis reduced our p95 latency from 800ms to 120ms. Here's my benchmark data. I want to validate this works in our actual environment before we commit."

Notice what's here:

Clear problem statement (latency under load)
Specific comparison (tested both)
Actual data (10k requests, p95 from 800ms to 120ms)
Next step (validate in real environment)
Humility (want to confirm before committing)

This engineer did the work. They have a theory. They tested it. They're ready to be wrong.

"I initially thought GraphQL was the right choice, but after prototyping, the complexity doesn't justify the benefits for our use case. Here's why I'm switching to REST endpoints."

This is intellectual honesty in action: changing your mind when reality doesn't match your theory. No ego. No doubling down. Just adaptation.

The Bad: Intellectual Dishonesty

"I just think this way is better."

Better how? For what? Compared to what? This is a non-answer masquerading as a decision.

"That's how we've always done it."

This is worse than "I don't know" because it pretends to be a reason. Tradition isn't reasoning. It's the absence of reasoning.

"The AI told me to do it this way."

Outsourcing your thinking to AI is outsourcing your judgment. If you can't explain why the AI's suggestion solves your problem better than alternatives, you don't understand what you're building.

How to Practice Intellectual Honesty

1. Write RFCs (Request for Comments)

Before building anything significant, write 1-2 pages explaining:

What problem you're solving
What alternatives you considered
Why you chose this approach
What the tradeoffs are

This forces you to think. You can't hide behind jargon in writing. If your reasoning is weak, it'll be obvious.

2. Build POCs (Proof of Concepts)

Don't just theorize. Test your assumptions. Build a small version. Measure real results.

"I think X will be faster" → Build both X and Y, benchmark them, show data.

3. Show Your Work

When you make a decision, document it. Not for bureaucracy. For clarity. Future you will forget why you chose this path. Your teammate needs to understand the reasoning to maintain it.

This means:

PRDs that explain the problem and why it matters
Test plans that show what you're validating and why
Benchmarks with real numbers, not hunches
Implementation plans that break work into reviewable pieces

4. Practice Saying "I Don't Know"

Make it a habit. When you don't know something, say it out loud. Then immediately follow with: "Let me find out."

This does two things:

It keeps you honest
It models good behavior for your team

The best engineers I know say "I don't know" constantly. The worst engineers never do.

5. Embrace Being Wrong

When evidence contradicts your theory, update your theory. Don't defend it. Don't rationalize. Don't save face.

Say: "I was wrong about X. Here's what I learned. Here's what I'm doing differently."

This is a superpower. Teams that can admit mistakes fix them fast. Teams that can't admit mistakes hide them until they explode.

The Test

Before your next technical decision, ask yourself:

"If someone asks me why I chose this approach, can I give them a clear, data-backed answer? Or will I bullshit?"

If the answer is bullshit, you're not ready to build yet. Go do the work. Test your assumptions. Build the POC. Get the data.

Then decide.

Strong Opinions, Loosely Held

This phrase gets thrown around a lot, but here's what it actually means:

Strong opinions: You have a clear point of view based on reasoning and evidence. You're not wishy-washy. You can articulate why you think X is better than Y.

Loosely held: You're ready to change your mind when new evidence emerges. You're not attached to being right. You're attached to finding the truth.

The combination is powerful: You move fast with conviction, but you adapt quickly when you're wrong.

The opposite is deadly: Weak opinions, strongly held. You don't really know why you believe something, but you'll fight to defend it anyway.

The Culture Shift

When you practice intellectual honesty, you change the culture around you.

Junior developers learn they can say "I don't know" without being judged. They learn to show their work. They learn to change their minds.

Senior developers stop pretending to know everything. They start testing their assumptions. They start asking "why" instead of just "what."

Code reviews become about ideas, not egos. The best argument wins, not the loudest voice or the highest rank.

This is how you build a team that ships great software. Not by pretending to have all the answers. By doing the work to find them.

Start Today

Pick one decision you're about to make. Before you make it:

Write down why you're considering this approach
List at least two alternatives
Explain the tradeoffs
Test your top choice if possible
Be ready to change your mind

That's it. That's intellectual honesty.

Do this consistently, and you'll build better software, grow faster, and earn the respect of everyone around you.

Not because you're always right. Because you're always honest.

This is part of a series on Core Leadership Principles for engineering teams. Next up: Ownership & Accountability - You own your code from concept to production.

Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.

Photo by Brett Jordan on Unsplash

How to Integrate Multiple LLM Providers Without Turning Your Codebase Into a Mess - Provider Strategy in Practice

Danilo Assis — Fri, 09 Jan 2026 02:24:50 +0000

Provider Strategy in Practice

How to Integrate Multiple LLM Providers Without Turning Your Codebase Into a Mess

Most companies eventually hit the same wall.

They start with one external provider — payments, maps, messaging, or LLMs. Everything works fine… until the day they need a second provider.

The main vendor goes down
Pricing changes
A specific feature exists only in another provider
Latency or regional availability becomes a problem

And suddenly, what used to be a clean integration becomes a maintenance nightmare.

This post walks through a practical, production-ready pattern to integrate multiple LLM providers while keeping your core platform clean, scalable, and resilient.

The Common Pain of Multi-Provider Integrations

When teams integrate providers directly into the domain logic, two types of complexity tend to leak into the system.

1. Provider-specific data leaks into the platform

Each provider has its own:

request and response formats
error codes
retry behavior
streaming protocols
rate limits
latency characteristics

Soon your core logic starts looking like this:

if (provider === "openai") {
  // handle OpenAI logic
} else if (provider === "gemini") {
  // handle Gemini logic
}

At this point, your domain layer is no longer about business rules — it is about vendor behavior.

2. Provider behavior leaks into the product flow

Different providers behave differently under load:

good p75 but terrible p99
aggressive throttling
partial outages
inconsistent output quality

Without isolation, every new provider:

increases regression risk
slows down development
makes refactoring scary

The result is predictable: giant integration files, fragile logic, and painful maintenance.

The Solution: Provider Strategy

To solve this problem, I like to use what I call Provider Strategy.

It is not a single pattern, but a combination of well-known patterns working together:

Strategy – each provider implements the same interface
Adapter – providers translate external formats into internal contracts
Registry – a central place to resolve the active provider
Failover Policy – logic to switch providers when the primary is degraded

The core principle is simple:

Treat external systems as external.

Your platform should only work with its own internal contract.

A Real Example: Services Marketplace Using LLMs

Imagine a platform that connects customers with professionals within a geographic range.

User input:

ZIP code
service type (e.g., mason)
desired date
optional notes

The platform:

Searches the database for available professionals
Aggregates ratings, availability, and pricing signals
Uses an LLM to generate a short, friendly proposal message

This is exactly the kind of flow that often starts with one provider and later needs multiple.

Step 1: Define a Stable Internal Contract

Your domain must not care which provider is being used.

type ProviderId = "openai" | "gemini" | "claude";

type LLMGenerateRequest = {
  prompt: string;
  temperature?: number;
  maxTokens?: number;
};

type LLMGenerateResult = {
  text: string;
  providerId: ProviderId;
  usage?: {
    inputTokens: number;
    outputTokens: number;
  };
};

This contract becomes the backbone of your platform.

Step 2: Provider Strategy + Adapter

Each provider implements the same interface and adapts its SDK internally.

type LLMProvider = {
  id: ProviderId;
  generate: (req: LLMGenerateRequest) => Promise<LLMGenerateResult>;
};

Example: OpenAI Provider

const openAIProvider: LLMProvider = {
  id: "openai",
  generate: async (req) => {
    const res = await openAIGenerate({
      prompt: req.prompt,
      temperature: req.temperature ?? 0.3,
      maxTokens: req.maxTokens ?? 300,
    });

    return {
      text: res.text,
      providerId: "openai",
      usage: res.usage,
    };
  },
};

Example: Gemini Provider

const geminiProvider: LLMProvider = {
  id: "gemini",
  generate: async (req) => {
    const res = await geminiGenerate({
      input: req.prompt,
      temp: req.temperature ?? 0.3,
      maxOutputTokens: req.maxTokens ?? 300,
    });

    return {
      text: res.outputText,
      providerId: "gemini",
      usage: res.usage,
    };
  },
};

Step 3: Provider Registry

Providers are registered at startup and resolved dynamically.

const createProviderRegistry = (providers: LLMProvider[]) => {
  const map = new Map(providers.map((p) => [p.id, p]));

  const resolve = (id: ProviderId) => {
    const provider = map.get(id);
    if (!provider) throw new Error(`Provider not registered: ${id}`);
    return provider;
  };

  return { resolve };
};

Step 4: Failover Policy + Circuit Breaker

Provider selection becomes a policy decision, not scattered logic.

const pickProvider = ({ primary, fallbacks, health }) => {
  const candidates = [primary, ...fallbacks];
  return candidates.find((id) => health(id) === "healthy");
};

This allows:

automatic failover
controlled retries
predictable p99 behavior

Putting It All Together

const generateProposal = async (input) => {
  const settings = await getPlatformSettings();
  const registry = createProviderRegistry([openAIProvider, geminiProvider]);

  const providerId = pickProvider({
    primary: settings.primaryProvider,
    fallbacks: settings.fallbackProviders,
    health: getProviderHealth,
  });

  const provider = registry.resolve(providerId);

  return provider.generate({
    prompt: buildProposalPrompt(input),
    temperature: 0.3,
    maxTokens: 220,
  });
};

Performance, p75, p99, and Cost Control

LLM systems often show:

good p75
poor p99

To control this:

aggressive timeouts
retry budgets
deterministic caching
async processing with queues
circuit breakers

Measure:

provider latency percentiles
retry rate
cache hit rate
token usage and cost

Monolith First, Microservices Later

This pattern works well in:

a single monolith
background workers
fully distributed systems

The internal contract stays stable while the architecture evolves.

Final Thoughts

Provider Strategy allows teams to:

isolate external complexity
scale integrations safely
improve reliability and p99
avoid vendor lock-in

Instead of fighting providers, your platform becomes provider-aware but provider-independent.

Follow me on Twitter
See more in https://linktr.ee/daniloab.

Photo by Denys Nevozhai on Unsplash

How do you know you are moving forward?

Danilo Assis — Mon, 20 Oct 2025 17:32:35 +0000

TLDR

Progress isn’t just about effort, it’s about direction. You move forward when you recognize patterns, adapt existing solutions to your context, and focus on the few actions that create the biggest results. Growth comes from learning, feedback, and alignment, not repetition.

How do you know you are moving forward?

Human life is surrounded by the anxiety of knowing if things are going as expected. Whether in childhood, youth, adulthood, or elderhood, it doesn’t matter. Humans will always seek dopamine as a way of reward. The human body and mind are strongly influenced by it.

As Arthur Schopenhauer said, “Life is a constant oscillation between the desire to have and the boredom of possessing.”

But how do you know you are moving forward? That’s a good question, and let’s dissect it below.

The Executive Challenge

In the executive field, you are constantly bombarded by deadlines and expectations, either from your leaders or yourself. Strategies, metrics, and plans must be well defined for each situation, although it is not always easy to achieve that.

For example, imagine a junior business analyst who has been requested to bring numbers about a specific company that seniors were studying for a case. By the time he presented his report, he had already reviewed three similar cases inside the company.

But the question is: Was he able to find the right approach? Which strategies could he pursue to achieve the expected result?

Problem Pattern Matching

Most problems have already been solved by someone before, and nowadays, with the internet, AIs, YouTube videos, and TikTok, solutions are widely available.

That is the moment when the ideas of Problem Pattern Matching and Smart Copy and Paste come into play.

Let’s imagine another situation: someone who has never cooked rice. What would that person do? They would probably look for references and sources on the internet, ask an AI, or watch a short video.

This is the core idea of Problem Pattern Matching: searching for patterns that already exist. That junior analyst could have applied this by looking at previous internal cases and how they had been approached.

Smart Copy and Paste

Once something relevant is found, it is time to apply the Smart Copy and Paste.

You might be wondering: “Okay, am I just going to copy and use someone else’s idea?”

Not exactly. The junior analyst should have adapted the model to his context instead of simply copying it. If he had just copied the previous report, the outcome would have been rejected by his leaders.

Instead, the solution had to be tested, adjusted, and improved. Just like I heard one: “You must adapt, not adopt.”

This is where feedback loops become essential. Solutions are improved when coworkers, leaders, or clients provide insights that help refine the final product.

Beyond the Limits

So, how do you know you are moving forward?

You know it when you can transform existing patterns into new solutions that fit your scenario, when you adapt instead of blindly copying, and when you use checkpoints and feedback loops to validate progress.

Moving forward means climbing beyond your limits, prioritizing the 20% of actions that generate 80% of results (Pareto Principle), and aligning with people who raise the bar with you.

References

The World as Will and Representation – Wikipedia
Pareto Principle – Wikipedia
Pattern Matching – Wikipedia
Learning Faster with the Cone of Learning – dev.to
Getting Ready for Daily Meeting – dev.to

Follow me on Twitter
If you like and want to support my work be my patreon
See more in https://linktr.ee/daniloab.
Photo by Richard Bell on Unsplash

What does it take to be a leader?

Danilo Assis — Fri, 05 Sep 2025 13:36:29 +0000

What is a Leader?

Being a leader is not an easy position, whether in the workplace, on a sports team, or within a family. Some might argue that leadership is innate, embedded in one’s character, disposition, and mindset. However, leadership can also be developed through deliberate practice. No one is born knowing everything; it is a journey that involves continuous learning, experience, and reflection. Those who aspire to lead effectively must first understand what leadership truly means.

It is essential to recognize that leadership is not only about taking the lead, but also about offering consistent support. A true leader is someone who understands the needs of their team and prioritizes collective success. Within a company, does it make sense to focus solely on individual performance, or should it also consider team performance? Leadership is not about acting as an independent contributor. It requires observing the team, identifying areas of difficulty, and assisting individuals in improving. This is precisely where many organizations have gone wrong, they often adopt short-term strategies, such as terminating underperformers, rather than investing in coaching and growth.

If a team of ten people is continuously reduced through dismissals instead of being supported and guided, the result will be the eventual breakdown of cohesion and productivity. Leaders should focus on strengthening the group, not weakening it. A successful team is built through collaboration, not competition. Effective leadership means committing to the development of others, enhancing performance and work quality, and guiding individuals toward their goals. Teams that receive support and feedback are often stronger and more resilient in the face of challenges.

Strategies and Resources

One of the most impactful resources on this topic is the book Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity, which provides a practical guide for leading without sacrificing empathy. Written by Kim Scott, a leadership expert who has worked with companies like Google and Apple, the book introduces the Radical Candor framework. This approach encourages leaders to care personally while challenging directly, striking a balance between compassion and accountability. Through real-world examples and actionable insights, Scott demonstrates how honest communication, when delivered with respect and clarity, can build trust, improve performance, and drive long-term results.

Organizations should aim to create environments where feedback is encouraged, people feel valued, and leadership is seen as a responsibility to serve the team. Otherwise, talent will continue to be lost, and the cycle of disengagement and high turnover will persist. After all, the best leaders are those who uplift others, not those who lead alone.

Bad Leadership Example

Consider a scenario where poor leadership had a direct negative impact on a team. A startup with ten developers, who were growing quickly and fully engaged, suddenly had new milestones added to their sprint. However, the team did not believe in the direction the project was taking and began discussing their concerns privately. Once leadership was made aware of these conversations, they faced a crucial decision. They could have responded by initiating open dialogue to clarify the vision and rebuild confidence, or they could have reacted defensively, assuming the team was being uncooperative.

Unfortunately, the leadership chose the second option, responding aggressively and treating the concerns as a threat rather than a warning. This decision broke the chain of trust and engagement. One by one, team members started to leave, seeking better environments where they could contribute meaningfully and be heard.

Lesson

What is the lesson here? Effective leadership is not just about setting goals; it is about supporting the people who are expected to reach them. A leader should have encouraged open communication, asked the right questions, and addressed doubts with transparency. Instead, the company has paid the price, both financially and culturally, by losing valuable talent, spending resources on hiring and training, and damaging team morale.

Leadership is an art. On one hand, a leader must be firm and decisive; on the other, they need to listen, care personally, and challenge directly, a core principle of Radical Candor. There is no need to be harsh or distant. With respect, clear feedback, and genuine care, leaders can build strong, motivated teams capable of overcoming challenges together.

Books remain one of the most valuable tools for learning, and leadership is no exception. In addition to Radical Candor, another powerful read is The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Although written as a novel, it offers practical and insightful lessons about leadership in high-pressure environments. The story follows Bill, an IT manager unexpectedly promoted to VP of Operations at a struggling company. Faced with missed deadlines, team dysfunction, and a failing initiative, Bill has just 90 days to turn things around. Through mentorship and experience, he learns how collaboration, process improvement, and effective leadership can drive real change. The book provides valuable takeaways on how leaders can navigate complex challenges, build trust, and enable their teams to succeed, no matter the industry.

References

https://www.radicalcandor.com/
https://www.amazon.com.br/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

Follow me on Twitter

If you like and want to support my work, become my Patreon

Want to boost your career? Start now with my mentorship through the Twitter DM!

https://mentor.daniloassis.dev

See more at https://linktr.ee/daniloab

Photo of Tobias Mrzyk in Unsplash

How to Use Google Sheets API with Node.js (Without SDKs or Consent Screen)

Danilo Assis — Tue, 05 Aug 2025 14:24:44 +0000

Recently, I've needed to integrate with Google Sheet APIs, and even though it's part of my normal daily routine, the knowledge I gained from that experience has motivated me to write this piece of code.

Mostly, people are used to connecting with Google Tools through the well-known consent page:

But, how does Google manage API requests for server-to-server services?

Let's take a deep dive and understand how to integrate Google Sheets without OAuth popups, SDKs, or real user interaction. In this post, I’ll show you how to use the Google Sheets API with a Service Account, generate your own JWT manually, and append data using native Node.js modules only — no SDKs.

Use Case

Internal tools
Server-side automations (e.g., CRON jobs)
No user login or consent screen

Step 1: Set Up a Google Service Account

1.1. Create a Google Cloud Project

Go to Google Cloud Console, create (or select) a project.

1.2. Enable the Sheets API

Search for “Google Sheets API” in the API Library, click Enable.

1.3. Create a Service Account

Go to IAM & Admin > Service Accounts
Click Create Service Account
After creation, go to the "Keys" tab and:
- Click Add Key > Create new key
- Select JSON and download it

**It's very important to save this JSON file because the code relies on it to save data to the spreadsheet through backend calls.

DON'T FORGET THIS STEP!**

1.4. Share the Spreadsheet

Open the JSON file, copy the client_email field, and share with your Google Sheet giving Editor access:
your-service-account@your-project.iam.gserviceaccount.com

Step 2: Write Code to Append Data

We'll create a script responsible for:

Generating the access_token responsible for claiming the API with the respective scopes on it.
Process the Google Spreadsheet API call.
It is expected you to serve the JSON file in some way. I'm using AWS secret manager with my keys already processed and just passing below to my google script file.

2.1 Google Service

Here, you can name it as you want. I will move forward, declaring it as a service:

export type GoogleServiceAccountJsonObjectKey = {
  type: string;
  project_id: string;
  private_key_id: string;
  private_key: string;
  client_email: string;
  client_id: string;
  auth_uri: string;
  token_uri: string;
  auth_provider_x509_cert_url: string;
  client_x509_cert_url: string;
  universe_domain: string;
};

const generateGoogleApiJWT = (googleServiceAccountJsonObjectKey: GoogleServiceAccountJsonObjectKey) => {
  logger.info('Starting generation of google api jwt token');
  const { client_email: clientEmail = '', private_key: privateKey, private_key_id: kid } = googleServiceAccountJsonObjectKey;
  const header = {
    alg: 'RS256',
    typ: 'JWT',
    kid,
  };

  const now = Math.floor(Date.now() / 1000);

  const payload = {
    iss: clientEmail,
    scope: 'https://www.googleapis.com/auth/spreadsheets',
    aud: 'https://oauth2.googleapis.com/token',
    iat: now,
    exp: now + ONE_HOUR_LATER,
  };

  const encodedHeader = base64url(JSON.stringify(header));
  const encodedPayload = base64url(JSON.stringify(payload));
  const unsignedToken = `${encodedHeader}.${encodedPayload}`;

  let sign;

  try {
    sign = crypto.createSign('RSA-SHA256');
    sign.update(unsignedToken);
    sign.end();
  } catch (error) {
    logger.error('Error in signing token', error);
    throw error;
  }

  const signature = sign.sign(privateKey, 'base64');

  return `${unsignedToken}.${signature}`;
};

const getAccessToken = async (jwt: string): Promise<string> => {
  logger.info('Getting google api access token');
  const params = new URLSearchParams({
    grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
    assertion: jwt,
  });

  const res = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: params,
  });

  const data = (await res.json()) as { access_token?: string };
  if (!res.ok) throw new Error(JSON.stringify(data));
  if (!data.access_token) throw new Error('No access_token in response');
  return data.access_token;
};

export const submitGoogleSpreadsheet = async <T>(
  body: T extends Record<string, unknown> ? T : never,
  googleSheetsAPIKey: GoogleServiceAccountJsonObjectKey,
  spreadSheetId: string,
) => {
  logger.info('Submitting google spreadsheet');

  if (!googleSheetsAPIKey || !spreadSheetId) {
    logger.error('');
    throw new Error('Missing google sheets api key or spreadsheet id');
  }

  let jwtToken;

  try {
    jwtToken = generateGoogleApiJWT(googleSheetsAPIKey);
  } catch (err: unknown) {
    logger.error('Failed to generate google api jwt', { err });
    return send(500, {});
  }

  let accessToken;

  try {
    accessToken = await getAccessToken(jwtToken);
  } catch (err: unknown) {
    logger.error('Failed to get google api access token', { err });
  }

  const bodyAsArray = Object.values(body).map((value) =>
    value === undefined || value === null ? '' : typeof value === 'boolean' ? (value ? 'yes' : 'no') : value.toString(),
  );

  const createdAt = new Date().toLocaleDateString('en-US', { year: 'numeric', month: '2-digit', day: '2-digit' });

  const fields = [...bodyAsArray, createdAt];

  logger.info('Spreadsheet fields', JSON.stringify(fields));

  const url = `https://sheets.googleapis.com/v4/spreadsheets/${spreadSheetId}/values/Sheet1!A2:append?valueInputOption=USER_ENTERED`;

  const response = await fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${accessToken}`,
    },
    body: JSON.stringify({
      values: [fields],
    }),
  });

  return response.json();
};

2.2 Calling the function

type MyType = {};

const spreadsheetId = "MY_SPREADSHEET_ID";

try {
    const googleSpreadsheetPayload = await submitGoogleSpreadsheet<MyType>(body, googleSheetsAPIKey, spreadsheetId);
    logger.info('Google spreadsheet submitted', { googleSpreadsheetPayload });
  } catch (error) {
    logger.error('Google spreadsheet error', error);
    return send(500, {});
  }

Security Tips

Never commit the Service Account JSON object to the file in Git.
Only expose as envs the values that you need.
Use .gitignore, secret managers, or environment variables.
Limit the spreadsheet access by not granting Drive-wide permissions.

Final Thoughts

This approach gives you full control of the Google Sheets API using standard Node.js, with no SDKs and no OAuth pop-up. It’s ideal for back-end scripts, internal dashboards, and server-to-server data automation.

References

Google Sheets API Reference

Google OAuth 2.0 for Service Accounts

Follow me on Twitter

If you like and want to support my work, become my Patreon

Want to boost your career? Start now with my mentorship through the Twitter DM!

https://mentor.daniloassis.dev

See more at https://linktr.ee/daniloab

Leveraging Native HTTP Caching in React Native (and Overriding It When Needed)

Danilo Assis — Fri, 20 Jun 2025 15:43:25 +0000

Improving performance in mobile apps is always a balancing act — especially when it comes to data fetching. You want to keep things fast, avoid unnecessary API calls, and ensure your users always see the most up-to-date information.

Recently, I ran into this exact challenge while working on a React Native app. I had a screen that fetched a list of specific entity based on a user ID. The data didn't change often, and yet every time the screen loaded, we made a fresh network call.

So, can we cache this response natively and skip the request unless it's really needed? The answer: yes — and React Native already gives us what we need.

Let’s walk through what I did.

The Problem

Imagine this:

fetch(`https://api.example.com/entity/123`)

You make this call when a user opens the app or navigates to a screen. Even if the data hasn't changed, the app hits the backend every time. This not only slows down the UI but also increases server load.

React Native, under the hood, uses:

OkHttp on Android
NSURLSession on iOS

Both of these support HTTP caching — meaning you can cache GET responses natively based on headers like Cache-Control.

But by default, React Native doesn't configure OkHttp for disk caching. So we first needed to get our backend and frontend talking the same cache language.

Step 1: Let the Backend Control the Cache

We updated our API to include a proper Cache-Control header:

Cache-Control: public, max-age=3600, must-revalidate

What does that mean?

public: this response can be cached by clients and shared caches (like proxies or CDNs)
max-age=3600: cache is fresh for 1 hour
must-revalidate: after 1 hour, the client must check with the server before reusing it

That tells native clients like OkHttp and NSURLSession: “You can safely cache this response for an hour.”

Step 2: Overriding the Cache When Needed

Now here’s the twist.

Sometimes, we wanted to force a fresh request, even if the cache was still valid — like when:

The app is reopened
The user manually refreshes the screen
We suspect stale data for any reason

We solved this by adding a Cache-Control: no-cache header on demand:

fetch('https://api.example.com/entity/123', {
  method: 'GET',
  headers: {
    'Cache-Control': 'no-cache',
  },
})
  .then(response => response.json())
  .then(data => {
    console.log('Fresh response:', data)
  })
  .catch(error => {
    console.error('Fetch error:', error)
  })

Final Thoughts

Caching can feel like a black box — especially in mobile apps — but understanding how native caching works under the hood unlocks a lot of power.

By:

Letting the backend control cache timing
Letting React Native honor the native cache
And providing a clean way to override it when needed

We got the best of both worlds: performance + flexibility.

This flow took a bit to learn, but once everything clicked, it became one of those “ohhh, this is super useful” moments.

Let me know if you want a full code example or a working demo!

Photo of Wouter R in Unsplash

What is a Ledger and Why Are Names Harder?

Danilo Assis — Wed, 26 Jun 2024 16:20:54 +0000

Portugues Version

What is Ledger Series

In software development, choosing appropriate names for variables, functions, and data structures is a crucial skill. Clear and consistent names are essential for code maintainability and for promoting a healthy development culture. Let's explore why names are important and how we can improve the readability and maintenance of our ledger example.

The Importance of Names

Clarity: Well-chosen names make the code easier to understand, both for the author and for other developers who will work on the project in the future.
Maintainability: Readable and clear code facilitates maintenance and updates, reducing the time needed to fix bugs or add new features.
Communication: Good names act as implicit documentation, helping to communicate the code's intent more effectively.
Consistency: Consistent names help establish patterns within the codebase, making it more predictable and less prone to errors.

Example Improvement: Changing transactionId to idempotencyId

In our previous example, we used transactionId to ensure transaction idempotency. While this name is clear, idempotencyId can be a more descriptive and precise name, reflecting its exact purpose.

Updating the Code

Let's update the code example to use idempotencyId instead of transactionId:

Defining the ledger structure in MongoDB:

{
  _id: ObjectId("60c72b2f9b1d8e4d2f507d3a"),
  date: ISODate("2023-06-13T12:00:00Z"),
  description: "Deposit",
  amount: 100000, // Value in cents
  balance: 100000, // Balance in cents
  idempotencyId: "abc123" // Idempotency ID
}

Function to add a new entry to the ledger and calculate the balance using idempotency:

const { MongoClient } = require('mongodb');

async function addTransaction(description, amount, idempotencyId) {
  const url = 'mongodb://localhost:27017';
  const client = new MongoClient(url);

  try {
    await client.connect();
    const database = client.db('finance');
    const ledger = database.collection('ledger');

    const existingTransaction = await ledger.findOne({ idempotencyId: idempotencyId });

    if (existingTransaction) {
      console.log('Transaction already exists:', existingTransaction);
      return;
    }

    const lastEntry = await ledger.find().sort({ date: -1 }).limit(1).toArray();

    const lastBalance = lastEntry.length > 0 ? lastEntry[0].balance : 0;

    const newBalance = lastBalance + amount;

    const newEntry = {
      date: new Date(),
      description: description,
      amount: amount,
      balance: newBalance,
      idempotencyId: idempotencyId
    };

    await ledger.insertOne(newEntry);

    console.log('Transaction successfully added:', newEntry);
  } finally {
    await client.close();
  }
}

addTransaction('Deposit', 50000, 'unique-idempotency-id-001'); // Value in cents

Conclusion

Choosing appropriate names is an essential part of software development. Clear, descriptive, and consistent names facilitate code readability, maintenance, and communication. In the example above, we changed transactionId to idempotencyId, making the variable's purpose clearer.

In our next post, we'll explore more about the importance of naming best practices and how they can positively impact code quality and development team efficiency.

Stay tuned for more insights on building reliable financial systems and development best practices!

Visit us Woovi!

Follow me on Twitter

If you like and want to support my work, become my Patreon

Want to boost your career? Start now with my mentorship through the link

https://mentor.daniloassis.dev

See more at https://linktr.ee/daniloab

Photo of Luca Onniboni in Unsplash

What is a Ledger and Why Floating Points Are Not Recommended?

Danilo Assis — Fri, 21 Jun 2024 20:37:29 +0000

Portugue Version

What is Ledger Series

In the realm of financial transactions and ledgers, accuracy is paramount. However, using floating point numbers to represent monetary values can lead to significant issues due to their inherent imprecision. This is why it's crucial to understand the problems with floats and consider alternative approaches.

Why Floating Points Are Problematic

Floating point numbers are a common way to represent real numbers in computing. However, they are not suitable for precise financial calculations due to rounding errors. Here are a few examples illustrating the issue:

console.log(0.1 + 0.2); // Expected: 0.3, Actual: 0.30000000000000004
console.log(0.1 + 0.2 === 0.3); // Expected: true, Actual: false

These small inaccuracies can accumulate over many transactions, leading to significant errors in financial records.

Using Cents or Decimal128

To avoid these pitfalls, it's recommended to represent monetary values in the smallest units (like cents) or use a data type designed for high precision, such as Decimal128 in MongoDB. This ensures that all calculations are exact, maintaining the integrity of financial data.

Updating the Example to Use Cents

We'll update our previous example to store amounts in cents instead of dollars, ensuring precision in our calculations.

Define the structure of the ledger in MongoDB using cents:

{
  _id: ObjectId("60c72b2f9b1d8e4d2f507d3a"),
  date: ISODate("2023-06-13T12:00:00Z"),
  description: "Deposit",
  amount: 100000, // Amount in cents
  balance: 100000, // Balance in cents
  transactionId: "abc123"
}

Function to add a new entry to the ledger and calculate the balance using cents:

const { MongoClient } = require('mongodb');

async function addTransaction(description, amount, transactionId) {
  const url = 'mongodb://localhost:27017';
  const client = new MongoClient(url);

  try {
    await client.connect();
    const database = client.db('finance');
    const ledger = database.collection('ledger');

    const existingTransaction = await ledger.findOne({ transactionId: transactionId });

    if (existingTransaction) {
      console.log('Transaction already exists:', existingTransaction);
      return;
    }

    const lastEntry = await ledger.find().sort({ date: -1 }).limit(1).toArray();

    const lastBalance = lastEntry.length > 0 ? lastEntry[0].balance : 0;

    const newBalance = lastBalance + amount;

    const newEntry = {
      date: new Date(),
      description: description,
      amount,
      balance: newBalance,
      transactionId: transactionId
    };

    await ledger.insertOne(newEntry);

    console.log('Transaction successfully added:', newEntry);
  } finally {
    await client.close();
  }
}

addTransaction('Deposit', 50000, 'unique-transaction-id-001'); // Amount in cents

Of course, if you are in prod making a change like this one it will need a migration of database. With mongo, this is easier. You can check how we handle this in our blogpost Zero Downtime Database Migrations at Woovi

The goal here is show what you can learn from common mistakes

Woovi APIs Use Cents

Woovi, a modern financial services platform, utilizes cents in their APIs to ensure precision and avoid the pitfalls of floating-point arithmetic. By doing so, they maintain the accuracy and reliability of financial transactions, which is crucial for both their operations and their customers' trust.

Conclusion

Implementing idempotency in your ledger system is crucial for maintaining accurate and reliable financial records. By ensuring that each transaction is only recorded once, you can prevent duplicate entries and maintain the integrity of your data.

As we have seen, idempotency is not just a technical detail but a fundamental principle that helps build robust and fault-tolerant systems. Similarly, using cents instead of floating points ensures precise financial calculations. In our next blog post, we will explore more advanced topics in ledger management and how to handle other challenges such as concurrency and eventual consistency.

Stay tuned for more insights into building reliable financial systems!

Visit us Woovi!

Follow me on Twitter

If you like and want to support my work, become my Patreon

Want to boost your career? Start now with my mentorship through the link

https://mentor.daniloassis.dev

See more at https://linktr.ee/daniloab

Photo of Andrew Spencer in Unsplash

What is Ledger and why does it need Idempotence?

Danilo Assis — Thu, 20 Jun 2024 22:14:43 +0000

PTBR Version

What is Ledger Series

In our previous blog post, we discussed what a ledger is and why it is essential to learn about it. We explored its origins, how it works, and its importance in financial institutions. Now, we will delve into a critical concept in building robust and reliable ledgers: idempotency.

What is Idempotency?

Idempotency is the property of certain operations that can be applied multiple times without changing the result beyond the initial application. In other words, if an operation is idempotent, performing it once or multiple times has the same effect. This concept is crucial in distributed systems, APIs, and financial transactions to prevent duplicate processing.

Why is Idempotency Important in a Ledger?

Preventing Duplicate Transactions: In a ledger, idempotency ensures that if a transaction is accidentally submitted more than once, it does not get recorded multiple times, which could lead to incorrect balances.
Consistency: Idempotency helps maintain the consistency and integrity of financial records, which is vital for audits and regulatory compliance.
Error Handling: Systems can safely retry operations without the risk of applying the same transaction multiple times, making the system more robust and fault-tolerant. Implementing Idempotency in a Ledger To illustrate how to implement idempotency in a ledger, we will update our previous example to include a transaction ID. This transaction ID will be used to ensure that each transaction is only recorded once.

Define the structure of the ledger in MongoDB:

{
  _id: ObjectId("60c72b2f9b1d8e4d2f507d3a"),
  date: ISODate("2023-06-13T12:00:00Z"),
  description: "Deposit",
  amount: 1000.00,
  balance: 1000.00,
  transactionId: "abc123"
}

Function to add a new entry to the ledger and calculate the balance with idempotency:

const { MongoClient } = require('mongodb');

async function addTransaction(description, amount, transactionId) {
  const url = 'mongodb://localhost:27017';
  const client = new MongoClient(url);

  try {
    await client.connect();
    const database = client.db('finance');
    const ledger = database.collection('ledger');

    // Check if the transaction already exists
    const existingTransaction = await ledger.findOne({ transactionId: transactionId });
    if (existingTransaction) {
      console.log('Transaction already exists:', existingTransaction);
      return;
    }

    // Get the last entry in the ledger
    const lastEntry = await ledger.find().sort({ date: -1 }).limit(1).toArray();
    const lastBalance = lastEntry.length > 0 ? lastEntry[0].balance : 0;

    // Calculate the new balance
    const newBalance = lastBalance + amount;

    // Create a new entry in the ledger
    const newEntry = {
      date: new Date(),
      description: description,
      amount: amount,
      balance: newBalance,
      transactionId: transactionId
    };

    // Insert the new entry into the ledger
    await ledger.insertOne(newEntry);

    console.log('Transaction successfully added:', newEntry);
  } finally {
    await client.close();
  }
}

// Example usage
addTransaction('Deposit', 500.00, 'unique-transaction-id-001');

How to keep the same transactionId?

Important: Your system needs to ensure that the transactionId is always created as expected to ensure that the transaction is unique. How to do this?

Let's assume you have an employee payment system and you cannot double pay employees. To do this, you can have a helper model that initiates a payment, a PaymentIntent. This PaymentIntent has the following model

{
  _id: ObjectId("60c72b2f9b1d8e4d2f508d82"),
  taxID: '12345678990', // cpf do funcionário
  description: "Salário",
  amount: 3000.00,
  status: 'PENDING',
  transactionId: '456',
  companyId: '123',
}

Once you call the entry creation function in the ledger you can create the transactionId by combining: company id + paymentIntent transactionId. Thus, every time you process the payment for that PaymentIntent, the same transactionId will always be created, ensuring that the Ledger can identify that entry.

Conclusion

As we have seen, idempotency is not just a technical detail but a fundamental principle that helps build robust and fault-tolerant systems. In our next blog post, we will explore more advanced topics in ledger management and how to handle other challenges such as concurrency and eventual consistency.

Stay tuned for more insights into building reliable financial systems!

Visit us Woovi!

Follow me on Twitter

If you like and want to support my work, become my Patreon

Want to boost your career? Start now with my mentorship through the link

https://mentor.daniloassis.dev

See more at https://linktr.ee/daniloab

Photo of The Creativv in Unsplash