DEV Community: Nahid Chowdhury

The Dependency Injection Secrets That Change How You Design Systems

Nahid Chowdhury — Wed, 25 Feb 2026 09:44:07 +0000

Introduction

In object-oriented programming, Dependency Injection is one of the most important design techniques for building scalable and maintainable large-scale applications. While it is often associated with OOP, the underlying idea is not limited to object-oriented languages and can also be applied in functional programming environments.

To truly understand Dependency Injection, we must first understand the principle behind it. Dependency Injection is not the goal itself—it is a technique used to achieve the Dependency Inversion Principle, one of the five SOLID principles.

DIP — According to Robert C. Martin

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

In a statically typed language, like Java, this means that the use, import, and include statements should refer only to source modules containing interfaces, abstract classes, or some other kind of abstract declaration. Nothing concrete should be depended on.

This is the formal definition of the Dependency Inversion Principle. In simpler terms, it means that we should depend on abstractions (interfaces or abstract classes) rather than concrete implementations.

❌ Violates DIP (high-level depends on low-level)

public class EmailSender
{
    public void Send(string to, string message)
    {
        Console.WriteLine($"Email to {to}: {message}");
    }
}

public class OrderService
{
    private readonly EmailSender _emailSender = new EmailSender(); // concrete dependency

    public void PlaceOrder(string customerEmail)
    {
        // order logic...
        _emailSender.Send(customerEmail, "Your order has been placed.");
    }
}

✅ Applies DIP + DI (depend on abstraction, inject implementation)

public interface INotifier
{
    void Notify(string to, string message);
}

public class EmailNotifier : INotifier
{
    public void Notify(string to, string message)
    {
        Console.WriteLine($"Email to {to}: {message}");
    }
}

public class OrderService
{
    private readonly INotifier _notifier;

    public OrderService(INotifier notifier) // injected abstraction
    {
        _notifier = notifier;
    }

    public void PlaceOrder(string customerEmail)
    {
        // order logic...
        _notifier.Notify(customerEmail, "Your order has been placed.");
    }
}

// Program.cs (Composition - Manual DI)

var notifier = new EmailNotifier();
var service = new OrderService(notifier);

service.PlaceOrder("nahid@example.com");

Understanding Dependency Injection

Now that we understand the Dependency Inversion Principle, let’s look at Dependency Injection.

As the example code block shows, manually injecting dependent objects requires initialization logic. For example, OrderService needs an EmailService, so the EmailService must be created beforehand. Now imagine that EmailService depends on an HttpService, which must also be created and passed in. Then HttpService depends on SocketService and CryptoService, which must also be instantiated and supplied.

The chain continues.

Managing this object graph manually quickly becomes complex and hard to maintain. Dependency Injection tools are designed to solve this problem—and more. At its core, a DI container helps us organize and resolve dependencies so we don’t have to manually construct and pass every dependency through every layer of the application.

Dependency Injection: Beyond the new Keyword

So far, we’ve discussed how Dependency Injection solves the problem of building and managing complex object graphs. But I also said it solves more than that.

You might be thinking: “My application is small. I don’t need a complex setup to manage my objects. Using the new operator in my controller, service, or repository layer is enough.”

But stop.

The real power of Dependency Injection goes beyond object creation. It directly impacts your application's performance and maintainability.

In the following sections, I will practically demonstrate how mismanaging—or completely ignoring—Dependency Injection can make your application worse than you expect. You’ll also see how proper use of DI can significantly improve both performance and long-term maintainability.

Object Creation Is Not Free

In object-oriented programming, object creation and lifecycle management are among the most critical aspects that require careful consideration.

According to the Gang of Four (GoF) design patterns, Creational Design Patterns (such as Singleton, Factory, etc.) primarily focus on managing object creation in a controlled and structured way.

So why should we care about object creation?

Because every object has both time and space complexity associated with it. Each object allocated in memory consumes space in the CLR heap (.NET), and its creation requires CPU cycles. Modern computers are fast, but at scale, these costs add up significantly.

To demonstrate this, I conducted a benchmark on the following machine:

CPU: Intel(R) Core(TM) i7-8700 @ 3.20GHz
Memory: 16 GB
OS: Windows 11
Runtime: .NET 9

The benchmark measured the overhead of creating an Entity Framework DbContext with three DbSets and tracking one active entity.

Benchmark Details:

Explore the Benchmark Code

Iterations: 100,000 (create context + touch model + track 1 entity)
Total time: 2.94 seconds
Average time per iteration: 29.39 µs (~0.029 ms) ~34,000 iterations per second
Total managed allocations: ~2.04 GB (≈ 1.90 GiB)
Average allocation per iteration: ~20.38 KB (≈ 19.9 KiB)

Even though each iteration seems inexpensive in isolation, 100,000 iterations resulted in over 2 GB of managed allocations. That is a significant amount of memory pressure, which directly impacts garbage collection and overall application performance.

The Performance Implications of Dependency Injection

The performance implications of Dependency Injection are largely determined by object (or service) lifecycles. A DI container forces us to think explicitly about how long each object should live within an application.

To understand its impact on performance, we must first understand the different lifetimes an object can have. I will use .NET as a practical example.

Think of an application like a hotel.

Different things inside a hotel have different lifetimes. The building is shared by everyone, all day, every day. It is not rebuilt for each guest. In a .NET application, this is like a Singleton service — created once and shared for the entire lifetime of the application process. Services such as logging, configuration, or caching usually belong to this category.

A hotel room, however, is assigned to one guest for the duration of their stay. It exists only during that stay and is reset afterward. In ASP.NET Core, this is similar to a Scoped service — created once per HTTP request and disposed at the end of that request. A DbContext is a perfect example of this lifetime.

Finally, consider a dental kit provided to a guest. It is created for immediate use and discarded afterward. This is like a Transient service — a new instance is created every time it is requested. Transient services are typically lightweight and stateless.

In a real OOP application, objects behave the same way. Some should live for the entire application lifetime, some should exist only within a request boundary, and others should be created per use. Choosing the correct lifetime is not just an architectural preference — it directly affects memory usage, garbage collection, concurrency safety, and overall performance.

Object Lifetime Management in ASP.NET Core DI
Let’s walk through a practical demonstration of how the .NET DI container manages object lifetimes — and how incorrect lifetime configuration can significantly degrade application performance.

// Program.cs - Correct lifetimes in .NET DI (baseline)

// app-wide
builder.Services.AddSingleton<ICache, MemoryCacheService>();    
// per request 
builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();
// per request (typical)         
builder.Services.AddScoped<AppDbContext>();
// per use                    
builder.Services.AddTransient<IJsonFormatter, JsonFormatter>();

Now let’s look at an example of inconsistent use of Dependency Injection.

public interface ITokenKeyStore
{
    byte[] GetKey();
}

public sealed class TokenKeyStore : ITokenKeyStore
{
    private readonly byte[] _keyMaterial;

    public TokenKeyStore()
    {
        // Simulate expensive initialization + memory allocation
        _keyMaterial = new byte[10 * 1024 * 1024]; // 10 MB
        new Random(42).NextBytes(_keyMaterial);
    }

    public byte[] GetKey() => _keyMaterial;
}

// ❌ BAD: creates a new 10MB object graph frequently → allocations + GC pressure
builder.Services.AddTransient<ITokenKeyStore, TokenKeyStore>();

// ✅ GOOD: create once, reuse safely (if thread-safe / immutable)
builder.Services.AddSingleton<ITokenKeyStore, TokenKeyStore>();

In this example, TokenKeyStore performs an expensive initialization. During construction, it allocates 10MB of memory and fills it with key material. This means that every time a new instance is created, the runtime must allocate a large object on the heap and eventually reclaim it during garbage collection.

If this service is registered as Transient, a new 10MB instance will be created every time it is requested from the container.

Under light development traffic, this may go unnoticed. But under real production load, frequent large allocations can:

Increase garbage collection frequency
Add CPU overhead
Reduce throughput
Introduce latency spikes

How DI Protects You from Circular Dependency Pitfalls

Let’s look at a simple example and understand circular dependency:

public class ServiceA
{
    private ServiceB _serviceB;
    public ServiceA()
    {
        _serviceB = new ServiceB();
    }
}

public class ServiceB
{
    private ServiceA _serviceA;
    public ServiceB()
    {
        _serviceA = new ServiceA();
    }
}

Now when we try to run:

var serviceA = new ServiceA();

What happens?

ServiceA creates ServiceB.
ServiceB creates ServiceA.
That new ServiceA creates another ServiceB.
And the cycle continues…

Until the runtime gives up with:

Stack overflow.
Repeated 12002 times...

This is a circular dependency—two services depending on each other in a loop. It becomes even more problematic when dealing with real-world, enterprise-grade applications that involve hundreds of objects interacting at the same time.

When using a DI container, this problem is detected early. Instead of crashing with a stack overflow, the container throws a clear exception saying a circular dependency was detected.

And that’s a good thing.

Because circular dependencies don’t just break your application — they signal that your design is fighting itself.

You can try it yourself:


// CircularService.cs
public class ServiceA
{
    public ServiceA(ServiceB serviceB) { }

    public void DoSomething()
    {
        Console.WriteLine("ServiceA is doing something.");
    }
}

public class ServiceB
{
    public ServiceB(ServiceA serviceA) { }

    public void DoSomething()
    {
        Console.WriteLine("ServiceB is doing something.");
    }
}

// Program.cs - Testing Circular Dependency
builder.Services.AddScoped<ServiceA>();
builder.Services.AddScoped<ServiceB>();

When we run this application using dotnet run, it throws an error during application startup:

Unhandled exception. System.AggregateException: Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: ServiceA Lifetime: Scoped ImplementationType: ServiceA': A circular dependency was detected for the service of type 'ServiceA'.

This is one of the real strengths of Dependency Injection. It prevents catastrophic runtime failures and forces architectural issues to surface early, before they evolve into performance bottlenecks or production outages.

Is There Any Performance Implication of Manual DI?

Yes — but not because manual DI is slow.

Manual DI is like driving a manual car. It’s perfectly fine. In fact, in the right hands, it can perform beautifully. But it requires discipline. You control when objects are created, how long they live, and when they are disposed.

And that’s exactly where things go wrong.

In small applications, manual DI works great. You create objects carefully, reuse what needs to be reused, and everything behaves. But as the application grows and more developers touch the code, new starts appearing everywhere. Heavy objects get recreated unnecessarily. Expensive resources are not reused. Disposal is forgotten.

Suddenly, memory usage increases, garbage collection runs more frequently, CPU usage spikes, and production starts behaving very differently from your local machine.

So no — manual DI isn’t slow.

But manual DI without strict lifetime discipline?
That’s how performance slowly degrades, one innocent new at a time.

The Maintainability Advantages of Dependency Injection

Performance matters. Stability matters.

But in real-world software, one thing matters even more:

Change.

Requirements change.
Business rules change.
Technologies change.
Teams change.

And the real question is not:

“Does my code work today?”

It’s:

“How painful will it be to change tomorrow?”

Let’s look at a simple example.

public class OrderService
{
    private readonly EmailService _emailService;

    public OrderService()
    {
        _emailService = new EmailService();
    }

    public void PlaceOrder()
    {
        // Business logic
        _emailService.SendReceipt();
    }
}

At first glance, this looks harmless.

But now imagine:

You want to switch from EmailService to SmsService
You want to mock notifications for testing
You want to introduce retry logic
You want to log notification failures

Now you must modify OrderService.

Your business logic is tightly coupled to a concrete implementation.

Now let’s refactor:

public interface INotificationService
{
    void SendReceipt();
}

public class EmailNotificationService : INotificationService
{
    public void SendReceipt()
    {
        Console.WriteLine("📧 Receipt sent via Email.");
        // real-world: SMTP/SendGrid/etc.
    }
}

// SMS implementation
public class SmsNotificationService : INotificationService
{
    public void SendReceipt()
    {
        Console.WriteLine("📱 Receipt sent via SMS.");
        // real-world: Twilio/etc.
    }
}

public class OrderService
{
    private readonly INotificationService _notificationService;

    public OrderService(INotificationService notificationService)
    {
        _notificationService = notificationService;
    }

    public void PlaceOrder()
    {
        _notificationService.SendReceipt();
    }
}

Now OrderService does not care:

Whether it’s email
Whether it’s SMS
Whether it’s a mock
Whether it’s a composite service

To switch implementations:

services.AddScoped<INotificationService, EmailNotificationService>();

// or

services.AddScoped<INotificationService, SmsNotificationService>();

No changes to business logic.

That’s maintainability.

And this is just the beginning.

So far, we only used DI to make one dependency replaceable. But once your codebase grows, DI unlocks a few other quiet advantages that most teams don’t fully take advantage of.

For example, DI makes it easy to add cross-cutting concerns—like logging, retries, caching, metrics, and tracing—without polluting your business logic. Instead of sprinkling try/catch, logger.Log(...), and retry loops inside every service, you can wrap behavior using decorators and keep the core logic clean.

DI also helps you catch design problems early (like circular dependencies) and gives you a single place to manage object lifetimes and disposal—both of which become huge for long-term stability.

I won’t dive deep into those topics here, because this article would turn into a book. But keep them in mind: once you start treating DI as a design tool—not just a convenience tool—it changes how you build and evolve systems.

Conclusion

Dependency Injection isn’t just about avoiding the new keyword. It’s about making your software behave like a well-managed hotel instead of a chaotic hostel where everyone builds their own room, shares the same toothbrush, and somehow the building gets rebuilt every time a guest checks in.

Used correctly, DI gives you control over lifetimes, protects you from circular dependency disasters, and makes change feel like a refactor—not a horror movie. Used incorrectly, it quietly burns CPU cycles, inflates memory, and makes production behave like it’s possessed.

So the next time you reach for new inside a controller, just remember: you’re not just creating an object, you might be creating a future outage.

Happy injecting — and may your dependencies never loop back to haunt you.😄

Beating Scope Creep: Implementing Extreme Prototyping (XPT) with GenAI Bolt, Figma & Postman

Nahid Chowdhury — Thu, 10 Jul 2025 04:52:47 +0000

What is Extreme Prototyping?

Extreme Prototyping (XPt) is a rapid, three-stage approach to building web-based (or API-centric) applications.
Its goal is to get a working version in front of users very quickly, then layer in functionality step-by-step—minimizing wasted effort on back-end details until the front-end experience is nailed down.

The Three Stages at a Glance

Stage	Purpose	Typical Deliverables	Key Roles Involved
Stage 1 – Static Mock-up	Nail the look-and-feel	Pure HTML/CSS (or low-code UI) with placeholder data	UX designer, front-end dev, product owner
Stage 2 – Simulated Services	Validate user flows	Same UI, but wired to stub or mock services that return canned JSON/XML	Front-end & back-end devs collaborate on service contracts
Stage 3 – Live Services	Make it real	Replace stubs with production-ready APIs, add persistence, security, performance	Full cross-functional team

Why Teams Use It

Instant feedback
Stakeholders click through a realistic UI in days, not weeks.
Reduced re-work
Because the front-end is proven early, fewer late-stage changes ripple into the back-end.
Parallel work streams
Back-end engineers can build real services in parallel with Stage 2 once contracts are frozen.
Risk containment
Usability and business-logic risks surface early; technical-integration risks are isolated to Stage 3.

Simple Walk-Through Example

Imagine you’re building an online travel-booking portal:

Stage	What You Release	What Users Can Do
1	Static pages: Search form, flight list, seat-selection pop-up.	Click around; see dummy fares and seats.
2	UI now calls `/flights/search` and `/seats/mock` endpoints returning hard-coded JSON.	Perform full booking flow, receive “Your reservation is #0000”. No real tickets issued.
3	Real payment gateway, live airline API, database persistence, auth.	Book and pay for an actual flight, get e-ticket, receive email confirmation.

At each stage, feedback loops stay tight: marketing tweaks copy in Stage 1, UX adjusts seat-map behavior in Stage 2, DevOps tunes API latency in Stage 3.

When Extreme Prototyping Shines

You’re building something from scratch.
Maybe it’s a brand-new web or mobile app and no one’s 100% sure how it should look or behave yet. XPT lets you get a clickable version in front of people fast—so you’re not guessing.
Your team is API-first or backend-heavy.
Stage 2’s mocked services mean your backend developers can define and build APIs independently, while the UI team moves ahead without waiting. Bonus: your mocks become living documentation.
You're juggling evolving requirements.
When product decisions shift mid-sprint, having a flexible front-end-first workflow makes it easier to adapt without breaking everything.

How Figma, Bolt New, and Postman fit into the picture

XPT Stage	Tools Used	How They Help
Stage 1 – Static Mock-up	Figma, GenAI Bolt	In Stage 1, Figma is used to quickly map out the look and feel of the app—think screens, buttons, and flow. GenAI Bolt steps in to fill those screens with realistic placeholder text, form fields, and sample data, so everything feels real enough for early feedback without writing a single line of backend code.
Stage 2 – Simulated Services	GenAI Bolt, Postman	In Stage 2, Postman’s Mock Servers let the team simulate how real APIs will behave—so the frontend doesn’t have to wait for the backend to be ready. It’s also the point where frontend and backend teams sit down and agree on the service contract (what data goes where, and how). GenAI Bolt helps by generating the glue code that connects the UI to these mock services, while Figma gets refined as real users click through and provide feedback.
Stage 3 – Live Services	Postman, GenAI Bolt, Figma (minor)	In Stage 3, Postman is used to test real APIs and make sure everything connects smoothly across systems. GenAI Bolt helps speed things up by generating boilerplate code and test cases, while Figma supports any last-mile UI tweaks—fine-tuning the interface before launch.

Quick Checklist to Get Started

Stage 1:

☐ Flesh out critical screens in Figma or code.
☐ Review with users; freeze visual design.

Stage 2:

☐ Define API endpoints & sample payloads.
☐ Wire UI to mocks; validate end-to-end journeys.
☐ Capture edge-cases and refine contracts.

Stage 3:

☐ Implement real services behind the same contracts.
☐ Add data persistence, security, and monitoring.
☐ Run full regression; launch!

Key takeaway

Extreme Prototyping (XPT) is all about getting real user feedback early—before diving deep into the technical build. It helps teams focus on what really matters to users first, while backend details catch up in parallel. The best part? XPT fits naturally into Scrum and sprint cycles, making it easier to demo working prototypes every sprint and ship the right product faster—without cutting corners on quality.

How to Write a Software Project Proposal: Complete Template & Guide

Nahid Chowdhury — Thu, 26 Jun 2025 05:53:50 +0000

Introduction

As a Software Architect, I was recently assigned to prepare a software project proposal for a client, which also involved conducting a requirement analysis in collaboration with our Business Analyst team to identify the functional and non-functional requirements. A significant part of software engineering is the systematic process of requirements engineering and the preparation of a comprehensive document known as the Software Requirements Specification (SRS). This document serves as an agreed-upon scope and working modality among all stakeholders. However, preparing such a document has not been within my comfort zone, as my experience over the past few years—as a Senior Software Engineer—has been primarily focused on development and reviewing technical artifacts.

After conducting research and holding several internal review sessions, we successfully compiled a format that addresses the needs of all stakeholders within a single comprehensive document.

Template

1. Cover Page

Project Title
Client Name / Organization
Submitted By (Company / Team)
Date

2. Table of Contents

The following section outlines the document's headings along with corresponding page numbers and hyperlinks for easy navigation.

3. Executive Summary / Project Overview

Brief description of the project
Business goals and objectives
Summary of proposed solution

4. Project Objectives

Specific outcomes the system aims to achieve
KPIs or measurable goals (if known)

5. Scope of Work

A. Functional Scope

Feature modules broken down by user type or system area (e.g., Customer, Admin, Vendor, etc.)

B. Out of Scope (Optional)

Clearly define what's not included to avoid scope creep

6. Technical Approach / Solution Architecture

High-level system architecture diagram (optional but recommended)
Data flow or component diagrams
Description of how the solution works at a technical level

7. Technology Stack

Layer	Technologies
Frontend	(e.g., React, Flutter)
Backend	(e.g., Node.js, Django)
Database	(e.g., PostgreSQL, MongoDB)
Hosting	(e.g., AWS, Azure)
CI/CD	(e.g., GitHub Actions)

8. Non-Functional Requirements (NFRs)

Performance
Scalability
Security (e.g., authentication, data protection)
Availability/Uptime
Compliance (if applicable)

9. Team Composition & Roles

List of team roles and responsibilities
Optional: resource allocation timeline (e.g., frontend dev full-time for 6 weeks)

10. Project Timeline / Milestones

Phase	Duration	Deliverables
Example: UI/UX Design	2 weeks	Wireframes, mockups

Include Gantt chart (optional but great for presentations)

11. Deliverables

List of tangible outputs (e.g., source code, documentation, deployed app, admin panel, etc.)

12. Assumptions & Dependencies

What you expect the client to provide
3rd party dependencies (e.g., payment gateway API access)
Timeline assumptions

13. Risk Analysis & Mitigation Plan

Risk	Impact	Likelihood	Mitigation

14. Change Management Process

How change requests will be handled
Approval workflow
Impact on timeline and cost

15. Communication & Reporting Plan

Meeting frequency (daily standups, weekly syncs)
Tools used (e.g., Slack, Jira, Google Meet)
Reporting responsibilities

16. Testing & Quality Assurance

Types of testing (unit, integration, UAT)
QA process and tools
Acceptance criteria

17. Deployment & Release Strategy

Staging and production environment
Rollout plan
Versioning and rollback strategy

18. Maintenance & Support Plan

Post-launch support (duration, scope)
SLA or response time for bugs
Optional: support tiers (e.g., Basic, Premium)

19. Cost Estimate / Pricing (Optional if pre-sales or internal)

Breakdown by deliverables, roles, or timeline
Payment schedule/milestones

20. Appendices

UI mockups
Sample diagrams
API documentation reference
Legal disclaimers or contracts

Conclusion

Writing a software project proposal used to feel outside my comfort zone—but through collaboration, research, and a bit of trial and error, I realized it’s just another form of clear, structured communication. This template isn’t just a checklist; it’s a bridge between technical minds and business goals. If you’re a developer or architect like me, I hope this format helps you feel more confident tackling the non-code side of software delivery. After all, great software starts with great understanding.

Demystifying Two Phase Commit (2PC) for Distributed Transaction in Microservices

Nahid Chowdhury — Mon, 27 Jan 2025 11:57:39 +0000

Introduction

Distributed transactions are a fundamental challenge in distributed systems. The rise of microservices architecture has amplified the importance of addressing this challenge effectively. Two-Phase Commit (2PC) is a well-established protocol designed to guarantee the reliable and consistent completion of transactions that involve multiple databases or systems. It remains a significant feature supported by many modern relational database management systems (RDBMS) such as Oracle and PostgreSQL. This post aims to demystify Two-Phase Commit (2PC) by implementing it using Node.js and PostgreSQL.

What is Two-Phase Commit (2PC)

Two-Phase Commit is a protocol for managing distributed transactions involving multiple databases or systems. It ensures data atomicity and consistency across multiple systems where a distributed transaction is necessary. It is primarily based on the RDBMS Prepared Transaction feature, which is supported by Oracle DBMS_TRANSACTION, PostgreSQL PREPARE TRANSACTION, and MS SQL Server Distributed Transaction Coordinator.

2PC involves two distinct phases.

Prepare Phase
In this phase, a coordinator informs related services to prepare a transaction with relevant data. However, the transaction remains in the staging area of RDBMS without impacting the actual data. For PostgreSQL, it can be viewed in the pg_prepared_xacts table. If transaction preparation is successful related services inform the coordinator service with a YES response.

Decision Phase
This phase is also known as Commit/Rollback Phase. If all the related services for the transaction reply with affirmative. The coordinator service informs related services to commit the prepared transaction.

if any of the related services failed to prepare the transaction and reply with NO. then the coordinator informs other services to rollback the prepared transaction. Thus it maintains atomicity and consistency in the data for multiple databases spanning throughout the different services.

Fig-1: Commit scenario for 2PC

Fig-2: Rollback scenario for 2PC

Preparing PostgreSQL for 2PC

In PostgreSQL, max_prepared_transactions parameter is used for controlling the number of prepared transactions that can be queued. Adjust it proportionally to your needs and resource availability in the database server.

For example, you can set this parameter in the postgresql.conf file located in /etc/postgresql/<version>/main/postgresql.conf in Ubuntu for default apt based installation.

max_prepared_transactions = 50

PostgreSQL Syntax for 2PC

PostgreSQL supports two-phase commit (2PC) using the commands PREPARE TRANSACTION '<tx_name>' and COMMIT PREPARED '<tx_name>'. The transaction name acts as the anchor between the prepare and commit phases, ensuring transaction consistency across multiple nodes or systems. Below is an example demonstrating 2PC functionality in PostgreSQL, which can be tested in pgAdmin.

-- Table Creation
CREATE TABLE IF NOT EXISTS public.students (
    id SERIAL PRIMARY KEY, 
    name TEXT UNIQUE,
    cgpa NUMERIC
);

-- Begin the transaction
BEGIN;

-- Perform some operations
INSERT INTO students(name, cgpa) VALUES('Khan', 3.80);

-- Prepare the transaction for future commit/rollback
PREPARE TRANSACTION 'txn_001';

-- Either commit the transaction at a later point in time
COMMIT PREPARED 'txn_001';

-- Or rollback the transaction using tx_name
ROLLBACK PREPARED 'txn_001';

Implementation in Node.js

In this example, Express.js and node-postgres have been used for API development.

const express = require("express");
const { Pool } = require("pg");
const crypto = require("crypto");

const app = express();

app.use(express.json());

// PostgreSQL connection details
const pool = new Pool({
  user: "postgres",
  host: "localhost",
  database: "testdb",
  password: "1234",
  port: 5432, // Default PostgreSQL port
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

/**
 * Health Check
 */
app.get("/health", (req, res) => {
  res.status(200).json({
    message: "Ok",
  });
});

/**
 * Prepare a Transaction for Commit
 */
app.post("/prepare", async (req, res) => {
  let result = null;
  let client = null;
  const { name, cgpa } = req.body;
  const transactionName = crypto.randomBytes(5).toString("hex");

  try {
    // Connect to the database
    client = await pool.connect();

    // Start the transaction
    await client.query("BEGIN");

    // Perform some operations
    result = await client.query(
      "INSERT INTO students (name, cgpa) VALUES ($1, $2) RETURNING id",
      [name, cgpa]
    );

    // Prepare the transaction
    await client.query(`PREPARE TRANSACTION '${transactionName}'`);

    console.log(`[INFO] Transaction '${transactionName}' prepared.`);
  } catch (error) {
    console.error("[ERROR] Error during transaction:", error.message);
    return res.status(500).json({
      message: error.message,
    });
  } finally {
    // Clean up and close the connection
    await client.release();
  }

  return res.status(201).json({
    id: result ? result.rows[0].id : null,
    txId: transactionName,
  });
});

/**
 * Commit the Transaction
 */
app.post("/commit", async (req, res) => {
  let client = null;
  const { txId } = req.body;

  try {
    // Connect to the database
    client = await pool.connect();
    // Commit the prepared transaction
    await client.query(`COMMIT PREPARED '${txId}'`);

    console.log(`[INFO] Transaction '${txId}' committed.`);
  } catch (error) {
    console.error("[ERROR] Error during transaction:", error.message);
    return res.status(500).json({
      message: error.message,
    });
  } finally {
    // Clean up and close the connection
    await client.release();
  }

  return res.status(200).json({
    txId: txId,
  });
});

/**
 * Rollback the Transaction
 */
app.post("/rollback", async (req, res) => {
  let client = null;
  const { txId } = req.body;

  try {
    // Connect to the database
    client = await pool.connect();
    // Commit the prepared transaction
    await client.query(`ROLLBACK PREPARED '${txId}'`);

    console.log(`[INFO] Transaction '${txId}' rollbacked.`);
  } catch (error) {
    console.error("[ERROR] Error during transaction:", error.message);
    return res.status(500).json({
      message: error.message,
    });
  } finally {
    // Clean up and close the connection
    await client.release();
  }

  return res.status(200).json({
    txId: txId,
  });
});

// Start the application
app.listen(3030, () => {
  console.log("[INFO] Server listening on port 3030");
});

Prepare API: Prepare a transaction with insert operation in students table. And returns the transaction name as txId in response.

curl --location 'http://localhost:3030/prepare' \
--header 'Content-Type: application/json' \
--data '{
  "name": "Nahid Chowdhury",
  "cgpa": "3.9"
}'

Commit API: Commit a staged transaction with transaction name (txId).

curl --location 'http://localhost:3030/commit' \
--header 'Content-Type: application/json' \
--data '{
    "txId": "7b8a1e6bc0"
}'

Rollback API: Rollback a staged transaction with transaction name (txId).

curl --location 'http://localhost:3030/rollback' \
--header 'Content-Type: application/json' \
--data '{
    "txId": "7b8a1e6bc0"
}'

Github Repo: node-pg-2pc

Conclusion

Two-Phase Commit (2PC) in PostgreSQL is a critical protocol for ensuring data consistency and integrity in distributed systems. By coordinating transaction preparation and finalization across multiple participants, 2PC provides a robust mechanism to manage complex transactions spanning multiple databases or nodes. While its implementation requires careful consideration of performance and failure scenarios, it remains an invaluable tool for systems demanding strong consistency.

Thank you for reading! If you have any questions or suggestions, feel free to reach out.

.NET Development Essentials on macOS with VS Code

Nahid Chowdhury — Sun, 29 Dec 2024 13:22:05 +0000

.NET 9 continues the tradition of Microsoft's commitment to performance, reliability, and developer productivity. With every iteration, .NET has gained features and optimizations that make it one of the leading platforms for modern application development. But unfortunately the most powerful IDE of .NET development Visual Studio isn't available on macOS.

Microsoft officially announced that they will no longer support Visual Studio for macOS and made VS Code the de-facto standard IDE for cross platform C# development. According to Microsoft official statement -

"While we have retired Visual Studio for Mac, we remain committed to our developers on Mac and .NET MAUI with alternatives like the C# Dev Kit for Visual Studio Code and other extensions you can use to take advantage of our ongoing investments in .NET development."

While VS Code with C# Dev Kit is a great choice but Visual Studio developers may need some guidance to effectively use VS Code with the C# Dev Kit. This blog post aims to provide a comprehensive guide to making .NET development on macOS feel like a native experience.

Install C# Extensions in VS Code

Here are some VS Code extensions to enhance your C# and .NET development experience.

C# Dev Kit
C# - Base Language Support
IntelliCode for C# Dev Kit

After installing the extensions the command palette of VS Code is supercharged with .NET related commands i.e. Create a New Project, Opening an Existing Solution, etc. So lets inspect the changes with (Command + Shift + P) and type .NET in the command palette.

Although the command palette offers a way to manage projects and solutions, using the .NET CLI directly can boost developer productivity.

The Concept of Solution and Project in .NET

In the .NET ecosystem, Solution and Project are foundational organizational concepts used within Visual Studio and other .NET development environments. They help developers manage the structure, dependencies, and workflow of software development.

Project:

A Project in .NET represents a single, self-contained unit of work or a collection of source files, references, and resources. It is essentially the building block of a .NET application. Defined by a .csproj or .vbproj file (depending on the language). For instance console project, web api project etc.

Solution:

A Solution is a container for organizing one or more related Projects. It provides a higher-level view of the application or system being developed. Defined by a .sln file and contains reference to multiple projects.

A Simple representation of Solution and Project Hierarchy

MySolution.sln
│
├── WebApp.csproj
│   ├── Controllers
│   ├── Views
│   └── Models
│
├── DataAccess.csproj
│   └── Repositories
│
└── Tests.csproj
    └── UnitTests

Managing Development with .NET CLI

Let's create an empty solution first so that we can add one or more projects later on. Create a folder and open the folder with VS Code. Inside the VS Code terminal run -

> dotnet new sln -n VsCodePlay

I have named the solution VsCodePlay, and an empty solution has been created named "VsCodePlay.sln".

Let's create a webapi project inside this solution with this command -

> dotnet new webapi -n Todo.API

A webapi project with all the weatherforecast boilerplate has been created but it's still not part of VsCodePlay.sln, We can inspect that in Solution Explorer of VS Code.

So run this command to add a project into a solution, The command should be run inside the root folder of the solution. In out case VsCodePlay folder -

> dotnet sln VsCodePlay.sln add Todo.API/Todo.API.csproj

I've included a second console application in the solution. The Solution Explorer now reflects this addition, as shown below. You can manage the application from the Solution Explorer alike Visual Studio.

You've already noticed that dotnet new command can create the boilerplate for you with just a single command. For inspecting the available project types in .NET you can run -

> dotnet new list

Using the .NET CLI, you can quickly generate a fully functional, basic project structure (boilerplate) for various project types, simply by using their short names.

We are now well-prepared to organize our project using the .NET CLI. Let’s explore some essential commands that will help streamline and manage our development process effectively.

Run the project in development mode

> dotnet run

If you don't want to restart the server manually for reflecting file changes then run the project in watch mode, It will continuously watch the file changes and automatically restart the server.

> dotnet watch run

Install a Nuget Package

> dotnet add package Newtonsoft.Json

Remove a Nuget Package

> dotnet remove package Newtonsoft.Json

Building a project for debugging

> dotnet build

Cleaning an existing build

> dotnet clean

Publishing a project as DLL in production

> dotnet publish "./Todo.API.csproj" -c Release -o ./publish

Publishing an entire solution

> dotnet publish -c Release

This command needs to be executed at the solution level.

Run the project in production mode

> dotnet ./publish/Todo.API.dll

Conclusion

VS Code, complemented by essential extensions and the .NET CLI, is a powerful tool for cross-platform C# application development. The insights shared in this post can help developers embrace .NET development on macOS, unlocking opportunities for innovation and project success.

Mount EBS Volume with EC2 Linux Instance

Nahid Chowdhury — Thu, 25 Jan 2024 10:44:15 +0000

Amazon Elastic Block Store (EBS) is an easy-to-use, scalable, high-performance block-storage service designed to work with EC2 instances. Unlike the instance store volume that comes with an EC2 instance, which is ephemeral and gets deleted when the instance is terminated, EBS volumes are independent of the instance and persist even after the instance is terminated. This means that any data written to the EBS volume will be preserved and can be accessed when the instance is restarted or launched again. There are several reasons why you might want to attach a separate EBS volume to an EC2 instance. Some of them are,

1. Data Persistence
2. Scalability and flexibility
3. Performance

In this blog post, we will learn about mounting an EBS instance in a Ubuntu Linux machine.

After attaching an EBS volume with a running EC2 instance, you can check it using the list block command

> lsblk

After that create a mount point in the /mnt folder.

> sudo mkdir -p /mnt/db

/mnt/db folder will be used for mounting the volume. So let's create the ext4 file system in the newly attached volume xvdf

> sudo mkfs -t ext4 /dev/xvdf

Now our file system is ready in the volume /dev/xvdf. For mounting it with /mnt/db we just need to use the mount command.

> sudo mount /dev/xvdf /mnt/db

Congratulations you have successfully mounted the volume and it's ready to use. For checking it you can use lsblk command.

For initializing the attached volume after an instance reboot/restart we can use the Linux file systems table /etc/fstab. Open the file /etc/fstab using nano and add the below-mentioned line at the end of the file.

/dev/xvdf   /mnt/db   ext4   defaults,nofail   0   2

Save & Close the file. Enjoy!

Generating Dynamic Breadcrumb Menus Using Tree Table & Recursive CTE

Nahid Chowdhury — Sat, 02 Dec 2023 15:19:34 +0000

It's a quite common pattern to store application navigation information in the database to achieve flexibility and control over generating dynamic menus based on roles. Many enterprise applications including large Core Banking Solutions with thousands of hierarchical navigation information store hierarchical data in a database using Tree Data Structure. However, there are a few different approaches that can be used to effectively store and manage tree data in an RDBMS. One of the common models is the Adjacency List Model. The adjacency list model is a straightforward approach to representing trees in an RDBMS. It involves storing each node in a separate row in a table, along with a reference to its parent node.

So In this blog post, we will learn about extracting the ancestor data of a menu item from RDBMS so that we can visualize the Breadcrumb Menu in the user interface.

Example of a Breadcrumb Menu

Prerequisites

Postgres database installed in Local / Cloud machine.
PgAdmin for executing the query and visualizing the result.
Prior knowledge of Recursive CTE will be helpful.

Preparing the Data

Let's create the Navigations Tree Table first.

CREATE TABLE navigations (
    id SERIAL PRIMARY KEY,
    title VARCHAR(50) UNIQUE NOT NULL,
    parent_id INT,
    created_on TIMESTAMP NOT NULL DEFAULT NOW(),
    FOREIGN KEY (parent_id) REFERENCES navigations (id)
);

Here we are storing id as a primary key and parent_id as a foreign key referencing the primary key of another row in the same table.

Our table is ready now. So let's insert some dummy data for navigation.

INSERT INTO navigations (title)
VALUES ('User');

INSERT INTO navigations (title)
VALUES ('Role');

INSERT INTO navigations (title, parent_id)
VALUES ('User Reports', (SELECT id FROM navigations WHERE title = 'User'));

INSERT INTO navigations (title, parent_id)
VALUES ('Daily Reports', (SELECT id FROM navigations WHERE title = 'User Reports'));

INSERT INTO navigations (title, parent_id)
VALUES ('User Activity', (SELECT id FROM navigations WHERE title = 'Daily Reports'));

INSERT INTO navigations (title, parent_id)
VALUES ('Role Reports', (SELECT id FROM navigations WHERE title = 'Role'));

After the successful execution of Insert Statements, we will have our tree structure ready for running the Recursive CTE.

Navigations Table

About Recursive CTE

A recursive common table expression (CTE) is a powerful tool for performing recursive queries in SQL. It allows you to traverse hierarchical data structures, such as trees or graphs, and perform operations on the data at each level of the hierarchy.

In Postgres, Recursive CTE can be defined using the WITH RECURSIVE clause. It consists of mainly two parts Anchor Query and Recursive Query combined by the UNION clause.

So let's print 1 to 10 using Recursive CTE and learn its building blocks without spending more time on theory.

WITH RECURSIVE counter AS (
    SELECT 1 AS count -- Anchor query return 1 (R0)
    UNION -- Combine R0 ... Rn
    -- Recursive Query increment count by 1
    -- Until its value reaches the limit / termination statement
    -- (R1 ... Rn)
    SELECT counter.count + 1 FROM counter
    WHERE counter.count < 10
)
SELECT * FROM counter; -- (Output: 1,2,3,4 ... 10)

Preparing the query for Breadcrumb Menu

So let's discuss the content of the Breadcrumb Menu. After clicking any menu item the user is usually routed to a new page/component. The Breadcrumb menu will visualize the path meaning the ancestor tree of a particular node. For instance, if a user clicks on the User Activity menu item the breadcrumb menu will display -

User > User Reports > Daily Reports > User Activity

A simple Recursive CTE can be used to extract data for equivalent output.

WITH RECURSIVE cte_get_parents AS (
    -- Anchor Query
    SELECT 
        id, 
        title, 
        parent_id, 
        created_on,
        0 AS level
    from navigations
    -- Title will be changed based on the user's click
    where title = 'User Activity'

    UNION

    -- Recursive Query
    SELECT 
        n.id, 
        n.title, 
        n.parent_id, 
        n.created_on,
        c.level - 1
    FROM navigations n INNER JOIN cte_get_parents c
    ON n.id = c.parent_id
)
SELECT 
    id, 
    title, 
    parent_id, 
    created_on,  
    level + (SELECT 
             ABS(MIN(level)) 
             from cte_get_parents
        ) AS level
FROM cte_get_parents
ORDER BY id ASC;

Explanations

The Anchor query returns the result of the node that we want to extract the ancestors. It also bootstraps the value of level so that we can track the depth of each node in the tree.
The recursive query takes the result of the anchor query and iterates the rows until parent_id becomes null.
As we are matching the ID of the table to the Parent ID of the CTE (ON n.id = c.parent_id), We are traversing the table bottom-up - One step towards the root after each iteration.
The recursive query terminates when the parent_id of an ancestor node becomes null (because no rows with the id null in the table). In our case the root node.
After termination of the recursive statement UNION will merge the results of Anchor and Recursive Statements.
The SELECT statement after the CTE expression will format the result in our desired format accessing the CTE result.

Final Result

After executing the Recursive CTE we will get the desired output. Thus, We can expose an API on top of it and visualize the result using a Breadcrumb UI component.

Output of the Recursive CTE

Conclusion

Tree tables are a fundamental data structure for representing hierarchical data in relational databases. They provide an efficient and organized way to store and manage parent-child relationships within a data model. Recursive CTEs (Common Table Expressions) emerged as a powerful tool for traversing and manipulating tree data structures in RDBMS. By leveraging the recursive nature of CTEs, users can effectively query and manipulate hierarchical data, enabling them to extract meaningful insights from complex data relationships.

From Navigations to Chart-of-Accounts, there are endless use cases of hierarchical data processing using Recursive CTEs.

Happy Coding!!!