WaveZync Blog – Tech, Product & Startup Insights

How TestPilot AI Turns Software Requirements Into Test Cases

Ramesh Lakmal — Wed, 15 Apr 2026 15:15:37 GMT

TestPilot-AI GitHub Repo

Writing Test Cases - The Work Behind the Work

“Why is this taking so long?” That was a question I heard a lot during my internship usually when I was deep in writing test cases, and honestly, sometimes I didn't have a good answer. It just takes time. You read the requirement, re-read it, think through the scenarios, write them out, and half the day is gone. Sometimes, with work piling up, we'd skip writing test cases altogether. Not because we didn't care, but because there wasn't enough time.

Under deadline pressure, most teams default to the happy path plus a handful of obvious negatives. Edge cases get missed. Coverage depends on who wrote the tests and how much time they had. When bugs slip through to production, the question is always: "Didn't we test this?"

That experience stuck with me. We had great tools for running tests, but nothing to help with the hardest part: figuring out what to test in the first place.

Why Test Design Techniques Matter

Test design techniques are systematic methods for deciding what to test. Instead of writing test cases based on gut feeling or whatever comes to mind first, these techniques give you a structured way to derive scenarios from the requirement itself. Each technique looks at the requirement from a different angle. One focuses on input boundaries, another on business rule combinations, another on how the system moves between states. The goal is to maximize the chance of finding bugs with a manageable number of test cases.

QA has well-established techniques for this. Boundary Value Analysis catches off-by-one errors by testing at the edges of input ranges. Decision Tables map out complex business rules with multiple conditions and their combinations. State Transition Testing models how the system moves between states and what happens on valid and invalid transitions. Equivalence Partitioning divides inputs into meaningful classes so you test one representative from each instead of every possible value.

These techniques aren't niche knowledge. They're part of standard QA training and most experienced engineers use them regularly. The real issue is time. When you're juggling multiple sprints, sitting down to formally apply five different techniques to a single requirement feels like a luxury you can't afford

What If AI Could Apply These Techniques For You?

The idea behind this project is what if AI could apply multiple QA techniques to every requirement, so you don't have to do it manually?

Not a single generic prompt like "write test scenarios for the given requirement." Anyone who's tried that in ChatGPT knows the result: a flat list of obvious scenarios with no structured depth. The problem is the AI tries to do everything at once and does nothing particularly well.

Our approach was to separate concerns and give the AI one technique at a time. "Apply Boundary Value Analysis" makes it focus on range edges and limits. "Apply State Transition Testing" makes it map lifecycle flows. Each technique becomes a separate lens. The results are noticeably more thorough than a single catch-all prompt.

TestPilot AI ships with 12 QA technique playbooks and applies them individually, then merges results into one clean suite. The skill library is just a folder of markdown files, so you can add your own custom techniques by dropping a new file into skills/. The system picks it up automatically. No code changes needed.

Under the Hood: A Step-by-Step Breakdown

Here's every internal stage, from the moment you provide a requirement to the final test suite on screen.

Step 1: Drop In Your Requirement

This step handles getting your requirement into the system and preparing it for AI processing.

1.1 Input Parsing

Three ways to provide your requirement: type it, upload a file, or pull from Jira. Whatever the format, the server converts it into clean plain text.

Input Method	What Happens Server-Side
Type / Paste	Text used directly, whitespace normalized
PDF upload	Binary parsed, layout artifacts removed
DOCX upload	Converted to raw text, formatting stripped
HTML upload	Scripts, styles, and markup stripped. Only body text is kept
Markdown upload	Used as-is
Jira import	REST API fetches story title, description, and acceptance criteria, then formats them into a structured block

The Jira integration browses your projects, epics, and sprints server-side, so credentials never touch the browser. By the time input reaches the AI, it's clean text with no formatting artifacts or binary noise.

1.2 Building the Analysis Prompt

The system doesn't just forward your text to the AI. It builds a structured request with two things: your clean requirement text, and a catalog of all available QA techniques (each listed by ID, title, and tags). The AI is prompted to act as a "senior QA engineer and test architect."

Step 2: Let the AI Read Between the Lines (Understanding What to Test)

This step is where the AI reads your requirement, figures out what's testable, and recommends which techniques to apply.

2.1 Clarify Requirements (Optional)

Requirements are rarely perfect. Before running the full analysis, you can optionally click "Find missing info" to have the AI identify ambiguities and gaps. It returns assumptions it would have to make and questions about unclear details, the same kinds of things a senior QA engineer would ask before writing test cases.

For example, "users can upload a profile photo" might trigger: What file formats are accepted? Is there a max file size? What happens if the upload fails?

You answer as many or as few as you want. Those answers get appended to the requirement as clarifications during generation. If you skip this step, the AI proceeds with its own assumptions (listed in the final output for your review).

2.2 Extracting Testable Elements

The AI reads through the requirement and pulls out everything that can be tested, categorized by type

Element Type	What It Means	Example
Input	Data the user provides	Email field, password field, age field
Output	What the system produces	Confirmation message, error alert
State	A condition the system can be in	Logged in, pending verification, locked
Rule	Business logic that governs behavior	"Users under 13 cannot register"
Boundary	Limits or thresholds	Password must be 8-64 characters
Constraint	Restrictions on the system	Max 3 login attempts before lockout
Action	Something the user does	Click submit, upload avatar
Integration	External system involved	Email service, payment gateway

These extracted elements become the foundation for technique selection. The AI uses them to decide which skills apply.

2.3 Scoring Techniques by Confidence

For each QA technique in the catalog, the AI checks whether the extracted elements match what that technique targets. It assigns a confidence level, a rationale, and an estimated scenario count.

Confidence	What It Means
High	Requirement clearly contains elements this technique targets
Medium	Elements are probably there but not spelled out explicitly
Low	Technique would be marginally useful for this requirement

Example for a "user registration form" requirement

Technique	Confidence	Rationale	Est. Scenarios
Equivalence Partitioning	High	Multiple fields with clear valid/invalid domains	8
Boundary Value Analysis	High	Explicit constraints: password 8-64 chars, age 13-120	10
Decision Tables	Medium	Conditional logic around verification + terms	6
State Transition	Medium	Flow has states (form → verify → active)	5
Error Guessing	High	Common failures: duplicate emails, injection, unicode	7
Non-Functional Baseline	Low	No explicit performance/security requirements stated	3
General Fallback	High	Always included as baseline	6

2.4 Validating the AI's Response

LLM output can't be blindly trusted. The system runs several checks:

Schema validation: Every response is checked against a strict JSON schema using Ajv, which verifies field types, required fields, and allowed values (e.g., confidence must be exactly "high," "medium," or "low"). If the response isn't valid JSON, the system tries to extract a JSON object from the text.

Self-repair loop: If validation fails, the system sends the errors back to the AI and asks it to fix and resubmit at a lower temperature. Two attempts before giving up.

Native JSON mode: For OpenAI and Gemini, the schema is passed directly to the API, constraining output format at the generation level.

Hallucination filtering: Any technique referencing a skill ID that doesn't exist in the library gets silently dropped.

General Fallback injection: If the AI omits the baseline technique, the system adds it automatically.

This doesn't make things perfect. But it helps ensure what reaches you is structurally valid and comes from real techniques.

2.5 You Review and Decide

The validated recommendations appear on screen, grouped by confidence (high, medium, low). You toggle techniques on or off. The AI suggests, and you have the final say on what gets generated.

Step 3: From Techniques to Test Cases

This step handles the actual test case generation, deduplication, and final output.

3.1 Creating Per-Skill Generation Tasks

For each technique you selected, the system creates a separate generation task. Each task bundles:

A focused system prompt: "You are a senior QA engineer specializing in [this technique]"
The full requirement text
The technique's markdown playbook (the skill file from skills/)
The extracted analysis context from Step 2.2

This is different from a single mega-prompt. Focused instructions produce more targeted results. "Apply Boundary Value Analysis" generates more precise boundary tests than asking the AI to handle six techniques at once.

3.2 Parallel Execution

Tasks go into a worker pool. Workers pull from a queue, and as one finishes, the next starts. Each call returns a mini test suite focused on that single technique.

Each mini-suite goes through the same validate-and-repair cycle from Step 2.4. If both attempts fail for a skill, it returns an empty suite instead of crashing the whole run. One bad response doesn't lose the others.

After validation, the skill ID is appended to every test case's coverage tags. A case from Boundary Value Analysis gets "boundary-value-analysis" in its tags, making it easy to trace which technique produced which case.

3.4 Test Case Structure

Every generated test case follows a consistent format:

Field	Description	Example
`id`	Sequential identifier	TC-001
`title`	Starts with "Verify that..."	Verify that login fails with empty password
`type`	Category from fixed set	negative, boundary, functional, security, ...
`priority`	Severity level	P0 (Critical), P1 (High), P2 (Medium), P3 (Low)
`preconditions`	Setup conditions	User is on login page, account exists
`steps`	Actions to perform	1. Leave password blank, 2. Click Login
`expected`	Expected outcome	Error: "Password is required"
`coverageTags`	Technique + domain tags	["boundary-value-analysis", "authentication"]
`requirementRefs`	Requirement traceability	["REQ-001"]

Here's what an actual generated test case looks like:

{
  "id": "TC-003",
  "title": "Verify that registration fails when password is shorter than 8 characters",
  "type": "boundary",
  "priority": "P0",
  "preconditions": [
    "User is on the registration page",
    "All other fields are filled with valid data"
  ],
  "steps": [
    "Enter a 7-character password in the password field",
    "Click the Register button"
  ],
  "expected": [
    "Registration is rejected",
    "Error message displayed: 'Password must be at least 8 characters'"
  ],
  "coverageTags": ["boundary-value-analysis", "registration", "password"],
  "requirementRefs": ["REQ-002"]
}

3.5 Combining All Suites

All mini-suites are pooled into one collection. Assumptions, risks, and missing-info questions from every skill are merged. Duplicate assumptions and risks are removed by exact lowercase match.

3.6 Weighted Jaccard Deduplication

When multiple techniques analyze the same requirement, overlap is inevitable. A BVA test and an Error Guessing test might both check what happens when a required field is empty. The system catches these by comparing every pair:

Dimension	Weight	Calculation
Title	40%	Tokenized, lowercased, Jaccard index (shared / total unique tokens)
Steps	40%	Steps concatenated and tokenized, same Jaccard
Expected results	20%	Expected concatenated and tokenized, same Jaccard

Score = 0.4 × title + 0.4 × steps + 0.2 × expected. Pairs exceeding 60% are flagged as duplicates and the newer one is dropped. Title and steps get more weight because they define what the test does. Two tests can have different expected outcomes but test the same scenario.

3.7 Renumber and Finalize

Surviving cases get fresh sequential IDs (TC-001, TC-002, ...) and are capped at a configured limit. The final suite is ready to view in the UI, export as PDF/CSV, or push to AIO Tests.

3.8 What the Final Output Includes (and Why)

The output isn't just a list of test cases. The final suite contains four distinct sections, each serving a different purpose:

Test Cases are the core output. Each one is a structured, atomic scenario with steps, expected results, priority, type, and traceability tags. These are the actual test scenarios ready to execute or push to your test management tool.

Assumptions are things the AI had to assume because the requirement didn't explicitly state them. For example, if the requirement says "users can reset their password" but doesn't mention how, the AI might assume "password reset is done via email link." These are listed so you can review them and catch any wrong assumptions before they turn into misleading test cases. If the AI assumed something incorrectly, you know which test cases to adjust or remove.

Risks are potential problem areas the AI identified while analyzing the requirement. These aren't test cases themselves, but flags for things that could go wrong. For example: "No rate limiting mentioned for login attempts, which creates a brute force risk" or "Requirement doesn't specify behavior when payment gateway is unavailable." Risks help you and your team prioritize what to test more carefully and what to raise with the product team. They're especially useful for junior QA engineers who might not spot these concerns on their own.

Missing Info Questions are things the AI couldn't determine from the requirement that would affect test design. These are similar to what the optional clarify step (Step 2.1) surfaces, but these come from the generation phase itself. For example: "What is the maximum number of items allowed in the cart?" or "Should the form auto-save drafts?" If you answered clarification questions in Step 2.1, you'll see fewer of these. The ones that remain highlight gaps in the requirement that you might want to take back to stakeholders.

Output Section	Why It Exists	What to Do With It
Test Cases	The actual test scenarios to execute	Review, refine, export, or push to AIO Tests
Assumptions	What the AI had to guess	Verify each one. Wrong assumptions mean wrong test cases
Risks	Potential problem areas spotted during analysis	Prioritize testing, raise with product team
Missing Info	Gaps that affect test coverage	Take back to stakeholders, or accept and move on

Together, these four sections give you more than just test cases. They give you a picture of how confident you can be in the output and where the requirement itself might need work.

3.9 Optional: Visual Technique Diagrams

You can toggle diagram generation for specific techniques. The AI generates a Mermaid.js diagram alongside the test cases, rendered directly in the UI.

Technique	Diagram Type	What It Shows
State Transition	State diagram	States, valid/invalid transitions
Decision Tables	Flowchart	Conditions branching to outcomes
Equivalence Partitioning	Flowchart	Input partitions: valid (green) vs invalid (red)
Boundary Value Analysis	Flowchart	Boundary points with pass/fail zones
Pairwise / Combinatorial	Flowchart	Parameter combinations as tree/matrix
Feature Decomposition	Mind map	Decomposed dimensions: actors, data, rules, states

The Skill Library: 12 Skills and Counting

The system ships with 12 playbooks, but this isn't a hard limit. Each skill is a markdown file in skills/ with frontmatter (ID, title, tags) and a body describing how to apply the technique. The server loads every .md file in that folder on startup. Want to add "API Contract Testing" or "WCAG 2.1 Checklist"? Drop in a markdown file and the system picks it up automatically.

#	Skill	What It Targets	Example Use Case
1	Equivalence Partitioning	Valid/invalid input classes	Email: valid format vs missing @, vs empty
2	Boundary Value Analysis	Edges of input ranges	Password: 7 (fail), 8 (pass), 64 (pass), 65 (fail)
3	Decision Tables	Multi-condition business rules	Member + coupon + $100 order = 20% off
4	State Transition	Lifecycle flows	Order: draft → submitted → approved → shipped
5	Pairwise / Combinatorial	Multi-parameter interactions	Browser × OS × language × payment method
6	Error Guessing & Heuristics	Common failure modes	SQL injection, special characters, empty arrays
7	Risk-Based Prioritization	High-impact scenarios first	Payment processing before cosmetic UI tests
8	Requirements Traceability	Full spec-to-test mapping	Every acceptance criterion traced to a test
9	Feature Decomposition	Atomic testable units	"Search" → query, filters, sort, pagination
10	Functional Core	Happy-path business logic	Login, add to cart, complete checkout
11	Non-Functional Baseline	Performance, security, usability	Page load < 3s, WCAG compliance, XSS checks
12	General Fallback	Catch-all baseline (always on)	Scenarios outside specific techniques

The more skills you add, the more the analysis engine can recommend.

The Human in the Loop

The generated test suite is a starting point, not a finished product. This is where your judgment comes in.

TestPilot AI doesn't know your system's history, your team's risk tolerance, or which integration partner has a flaky API. Those calls are yours.

What TestPilot AI Tries to Do	What You Still Need to Do
Apply available QA techniques	Decide which edge cases matter for your system
Generate structured test cases	Review and refine with domain knowledge
Remove overlapping scenarios	Add context-specific tests the AI can't know
Get you a first draft quickly	Make the final priority and risk calls

Some cases will be spot-on. Others might be too generic or miss a nuance only you'd catch. The value is in not starting from a blank page. You review, edit, and then export as PDF, CSV, or push directly to AIO Tests.

The goal was never to replace QA engineers. It was to spend less time typing and more time thinking. That's what we built TestPilot AI to help with.

Observability in Node.js & NestJS: Tracing and Logging with OTel, Tempo, and Loki

Rasika Lakmal — Thu, 19 Mar 2026 13:18:00 GMT

Modern distributed applications can become complex very quickly. Tracking down performance bottlenecks or debugging request flows across microservices is challenging without proper observability.

That’s where OpenTelemetry (OTel) comes in. Combined with Grafana Tempo for distributed tracing, Grafana Loki for logging, and Grafana dashboards for visualization, you get a powerful stack to collect, store, and analyze your system's behavior seamlessly.

In this tutorial, we’ll build a robust observability pipeline. We will setup a standard Node.js (Express) application and a NestJS application, wire them up with OpenTelemetry, and correlate their logs and traces using a Docker Compose stack.

💡 Get the Code: The complete source code for this tutorial is available on GitHub.

🚀 What We're Building

By the end of this guide, you will have:

A Node.js (Express) API automatically instrumented with OpenTelemetry.
A NestJS API, also instrumented, receiving requests from the Express API to demonstrate distributed tracing.
A Docker Compose stack running Grafana, Tempo, Loki, and the OTel Collector.
Seamless log-to-trace correlation in Grafana (clicking a log instantly opens the related trace).

Why this stack?

OpenTelemetry: Vendor-neutral standard for telemetry data.
Grafana Tempo: A high-volume, minimal-dependency distributed tracing backend.
Grafana Loki: A highly efficient log aggregation system designed specifically to work well with Grafana and Prometheus/Tempo.
Grafana: The extensive visualization platform everyone loves.

Step 1: The Infrastructure (Docker Compose)

Let's use docker-compose to orchestrate Tempo, Loki, the OTel Collector, and Grafana entirely.

Create a docker-compose.yml in your project root:

version: "3.8"
services:
  # 1. Grafana Tempo (Tracing Backend)
  tempo:
    image: grafana/tempo:latest
    command: ["-config.file=/etc/tempo.yaml"]
    volumes:
      - ./docker-config/tempo.yaml:/etc/tempo.yaml
    ports:
      - "3200:3200"
      - "4317"

  # 2. OpenTelemetry Collector (The middleman)
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel-collector.yaml"]
    volumes:
      - ./docker-config/otel-collector.yaml:/etc/otel-collector.yaml
    ports:
      - "4317:4317" # OTLP gRPC receiver
      - "4318:4318" # OTLP HTTP receiver
    depends_on:
      - tempo
      - loki

  # 3. Grafana Loki (Logging Backend)
  loki:
    image: grafana/loki:latest
    command: ["-config.file=/etc/loki.yaml"]
    volumes:
      - ./docker-config/loki.yaml:/etc/loki.yaml
    ports:
      - "3100:3100"

  # 4. Grafana (Visualization User Interface)
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    volumes:
      # Auto-provision data sources including our Loki -> Tempo derived field
      - ./docker-config/grafana-datasources.yaml:/etc/grafana/provisioning/datasources/datasources.yaml
    depends_on:
      - tempo
      - loki

The Magic: Grafana Configuration

To connect Logs to Traces automatically, we provision the datasources via docker-config/grafana-datasources.yaml:

apiVersion: 1
datasources:
  - name: Tempo
    type: tempo
    uid: tempo
    access: proxy
    url: http://tempo:3200
  - name: Loki
    type: loki
    uid: loki
    access: proxy
    url: http://loki:3100
    jsonData:
      derivedFields:
        - datasourceUid: tempo
          matcherRegex: '"trace_id":"(\w+)"'
          name: traceID
          url: "$${__value.raw}"

Pro Tip: The derivedFields block tells Grafana: "When you see a trace_id in a Loki log, make it clickable and open that ID in Tempo."

(For otel-collector.yaml, tempo.yaml, and loki.yaml, refer to standard minimal configurations, pointing OTLP exports to Tempo and Loki).

Step 2: Instrumenting a Node.js (Express) App

To automatically instrument an Express application and send logs with injected trace IDs, you need the OpenTelemetry node SDK and a logger like winston.

npm install express winston winston-loki @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http @opentelemetry/resources @opentelemetry/semantic-conventions

Create instrumentation.ts. This file must be imported before anything else in your app to ensure auto-instrumentation wraps the require calls.

// instrumentation.ts
import { NodeSDK } from "@opentelemetry/sdk-node";
import { Resource } from "@opentelemetry/resources";
import { ATTR_SERVICE_NAME } from "@opentelemetry/semantic-conventions";
import { OTLPTraceExporter as OTLPHttpExporter } from "@opentelemetry/exporter-trace-otlp-http";
// import { OTLPTraceExporter as OTLPGrpcExporter } from '@opentelemetry/exporter-trace-otlp-grpc';
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node";

const sdk = new NodeSDK({
  resource: new Resource({ [ATTR_SERVICE_NAME]: "express-api" }),
  // Defaulting to HTTP for highest cross-network compatibility
  traceExporter: new OTLPHttpExporter({
    url: "http://localhost:4318/v1/traces",
  }),
  // To use gRPC instead (High performance, Port 4317):
  // traceExporter: new OTLPGrpcExporter({ url: 'http://localhost:4317' }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Inside your index.ts:

import express from "express";
import winston from "winston";
import LokiTransport from "winston-loki";

// Winston combined with OTel's auto-instrumentation will automatically
// append `trace_id` and `span_id` into the JSON logs!
const logger = winston.createLogger({
  format: winston.format.json(),
  transports: [
    new winston.transports.Console(),
    new LokiTransport({ host: "http://localhost:3100", json: true }),
  ],
});

const app = express();
app.get("/hello", async (req, res) => {
  logger.info("Received request on /hello");
  // ... make request to NestJS API ...
  res.json({ message: "Hello from Express" });
});
// ... listen on port

Step 3: Instrumenting a NestJS App

For NestJS, the setup is incredibly similar. The key difference is we add @opentelemetry/instrumentation-nestjs-core for framework-specific lifecycle hooks.

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http @opentelemetry/instrumentation-nestjs-core nest-winston winston winston-loki

Your NestJS instrumentation.ts will look just like the Express one, but with an added array item:

import { NestInstrumentation } from '@opentelemetry/instrumentation-nestjs-core';
// ...
  instrumentations: [
    getNodeAutoInstrumentations(),
    new NestInstrumentation(),
  ],
// ...

In your NestJS main.ts:

import "./instrumentation"; // <--- MUST BE THE VERY FIRST IMPORT
import { NestFactory } from "@nestjs/core";
import { AppModule } from "./app.module";

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  // ...
}
bootstrap();

Step 4: Launch and Verify

Start the Infrastructure:

docker-compose up -d

Start your Apps:Run both your Express and NestJS apps locally with the instrumentation.ts loaded.
Generate Traffic:Hit your Express API endpoint, which in turn calls your NestJS API:

curl http://localhost:3000/hello

Step 5: Analyzing Logs and Traces in Grafana

Now that our system is generating telemetry, let's look at how to actually use it to debug a request flow.

1. Querying Logs in Loki

Open Grafana at http://localhost

and navigate to the Explore tab. Select your Loki datasource. You can query logs by service name. For example, run: {service_name="express-api"}

2. Discovering the Trace ID

Expand one of the log lines. Because of our OpenTelemetry and Winston integration, you will notice that a trace_id and span_id have been automatically injected into the JSON payload of the log.

Because we configured derivedFields in our Grafana datasources, Grafana recognizes this trace_id and automatically generates a clickable button right next to it!

3. Visualizing the Distributed Trace in Tempo

Click that trace ID link. Grafana will seamlessly open a split-screen view querying Tempo for that exact trace.

You will be presented with a Waterfall visualization of the entire lifecycle of that single HTTP request. You'll be able to see:

The exact millisecond the request hit the Express API.
The duration of the Express API processing.
The exact moment the Express API made the downstream HTTP call to the NestJS API.
How long the NestJS API took to route and respond to the request.

If an error occurred anywhere in this chain, the specific span would be highlighted in red, immediately pointing you to the failing microservice without having to guess!

🔧 Troubleshooting Guide

If things aren't working, don't panic. Distributed tracing involves several moving parts. Here is a checklist to resolve common issues.

1. "I don't see any traces in Grafana"

App -> Collector: Look at your console. Do you see HTTP/gRPC errors like ServiceUnavailable? Ensure the OTLP Endpoint is correct (localhost:4317 locally vs otel-collector:4317 in Docker).
Collector -> Tempo: Check logs: docker logs otel-collector. Look for connection refused errors. Ensure the collector is connecting to tempo:4317.
Protocol Mismatch: Default OTLP exporters typically use gRPC port 4317. HTTP endpoints use 4318. Don't mix them up!

2. "My trace_id is missing from Loki logs"

Ensure you are using winston.format.json() if you are relying on OTel's auto-injection. The Node SDK hooks into Winston's JSON formatting to silently inject active span context.
Make sure --require ./instrumentation.ts is actually running before your app boots.

⚖️ gRPC vs HTTP for OTel Exporters

You'll notice we provided both HTTP and gRPC exporters in the example code.

gRPC (Port 4317): The default and highest performing protocol for OpenTelemetry. It relies on HTTP/2 multiplexing and binary Protobuf streams, vastly reducing network overhead. However, certain strict corporate proxies, older load balancers, or intricate Docker networking rules can struggle to route raw HTTP/2 traffic seamlessly.
HTTP/Protobuf (Port 4318): Packs the exact same Protobuf binary structures but relies on standard HTTP POST requests. It's incredibly robust, bypasses practically all proxy routing issues out of the box, and is significantly easier to start with at the cost of slight performance overhead.

If you are debugging locally or running into Connection Refused traces, HTTP is your safest bet!

Conclusion

You have effectively built a robust observability pipeline. By instrumenting early, centralizing traces in Tempo, aggregating logs in Loki, and gluing them together in Grafana, you eliminate the guesswork when microservices start passing messages. You can now trace a user's action seamlessly through your entire architectural stack!

How AI Is Transforming the Business Analyst Role 🤖

Nimesha Manchalee — Mon, 16 Feb 2026 19:25:26 GMT

Smarter and Faster Data Analysis

Data is the foundation of business analysis. In the past, Business Analysts spent a large portion of their time cleaning datasets, organizing spreadsheets, and manually identifying trends. This process was slow and often exhausting.

AI powered analytics tools now automate much of this work. Tools such as Microsoft Power BI with AI visuals, Tableau with Einstein Discovery, and Google Looker use machine learning to automatically detect trends, outliers, and patterns in data. Platforms like Alteryx and RapidMiner also help automate data preparation and advanced analytics without heavy coding. This allows Business Analysts to spend less time preparing data and more time interpreting insights that influence business decisions.

Predictive Insights and Forecasting

AI enables Business Analysts to move beyond reporting past performance and into forecasting future outcomes. Predictive analytics tools analyze historical data and generate forecasts that support better planning. Tools such as IBM Watson Analytics, SAS Forecasting, and Azure Machine Learning allow Business Analysts to build models that predict customer behavior, sales trends, and operational risks. Even spreadsheet tools like Excel now include AI-powered forecasting features that make predictive analysis more accessible with these tools. Business Analysts can help organizations anticipate demand, reduce risks, and make proactive decisions rather than reactive ones.

Improved Requirements Gathering

Requirements gathering is one of the most important responsibilities of a Business Analyst. It involves understanding stakeholder needs and documenting them clearly. AI is making this process more efficient and accurate. Meeting intelligence tools like Otter.ai and Microsoft Copilot can transcribe meetings and summarize key discussion points. Natural language processing tools can extract action items and highlight decisions from long conversations. Documentation assistants such as Notion AI and Confluence AI help Business Analysts organize and refine requirements into structured documents. These tools reduce manual note-taking and minimize the chances of missing important information, resulting in clearer and more complete requirement documentation.

Better Communication with Stakeholders

Business Analysts must communicate complex ideas in ways that both technical and non-technical stakeholders can understand. AI helps transform raw data into clear insights and professional reports. Tools like ChatGPT, Microsoft Copilot, and Google Gemini can assist in drafting reports, summarizing findings, and simplifying technical explanations. Visualization platforms such as Power BI and Tableau use AI features to automatically generate charts and narrative summaries that explain trends in plain language. This improves clarity, speeds up report preparation, and helps Business Analysts focus more on discussion and decision-making rather than formatting documents.

Process Optimization and Automation Opportunities

Analyzing and improving business processes is a core part of the Business Analyst role. AI-powered process mining and automation tools provide deeper visibility into how processes actually work. Tools such as Celonis and UiPath Process Mining use AI to analyze system logs and identify inefficiencies, delays, and bottlenecks. Business Analysts can use these insights to recommend process improvements and automation opportunities. Robotic Process Automation tools like Automation Anywhere and UiPath also help implement solutions for repetitive manual tasks. This makes Business Analysts key contributors to operational efficiency and digital transformation initiatives.

Stronger Decision Support

AI enhances decision support by enabling data-driven comparisons between different business scenarios. Business Analysts can evaluate potential outcomes and risks before decisions are made. Decision intelligence platforms such as Palantir Foundry and SAP Analytics Cloud use AI to simulate business scenarios and provide recommendations. Business Analysts can use these tools to support leadership with evidence-based insights that strengthen strategic planning. This elevates the Business Analyst from a support role to a trusted advisor who influences important business decisions.

More Time for Strategic and Creative Work

AI automates many routine tasks such as report formatting, basic analysis, and data organization. This frees up time for Business Analysts to focus on work that requires creativity and critical thinking.

They can spend more time identifying innovative solutions, improving stakeholder relationships, and aligning projects with long-term business strategy. AI becomes a productivity partner that handles repetitive work while the Business Analyst focuses on value creation.

The Human Element Still Matters

Despite the rise of AI, human skills remain essential. Business Analysts often manage conflicting stakeholder expectations, handle sensitive business issues, and make judgments in situations where data alone is not enough. Empathy, negotiation skills, ethical decision-making, and deep understanding of business context cannot be replaced by machines. The most successful Business Analysts will be those who combine strong interpersonal skills with the ability to use AI tools effectively.

Conclusion

Artificial Intelligence is transforming the Business Analyst role into a more strategic, efficient, and insight-driven profession. By automating routine tasks and enhancing analytical capabilities, AI allows Business Analysts to deliver deeper insights and support smarter decisions. Rather than replacing Business Analysts, AI is empowering them. Those who embrace AI tools such as Power BI, Tableau, ChatGPT, Copilot, Celonis, and predictive analytics platforms will be better equipped to lead change and add meaningful value in a data-driven business world.The future of business analysis lies in the collaboration between human intelligence and artificial intelligence.

Setting Up a QA Workflow with Playwright, GitHub Actions and AIO Tests

Ramesh Lakmal — Wed, 31 Dec 2025 08:49:35 GMT

⚙️ Getting Started with AIO Tests Integration

AIO Tests is a Jira-integrated test management tool that helps QA teams manage manual and automated tests with real-time tracking and detailed reporting. It streamlines the testing process while ensuring full traceability from requirements to defects. This article aims to show how to integrate GitHub Actions with AIO Tests to trigger Playwright test workflows directly from the AIO Tests interface. We'll use the native AIO Tests Playwright reporter for automatic test case updates. AIO Tests also supports other reporting options such as manual uploads and API-based integration.

📃 Prerequisites

Before you begin, make sure you have the following:

✅ Set of pre-written Playwright test scripts in your project and create a GitHub repository to manage them

✅ An active Jira account with access to your project

✅ The AIO Tests app installed from the Atlassian Marketplace

🤖 Playwright Framework Overview

This project uses Playwright, a powerful open-source tool by Microsoft for end-to-end testing of web applications across modern browsers like Chrome, Firefox, and Safari. Playwright supports fast, reliable testing with features like auto-waiting, network control, and multilanguage support.

The framework is structured using the Page Object Model (POM) for maintainability and scalability. Key folders include (GitHub Repo):

🖇️ Link AIO Test Cases with Playwright Scripts

Step 1 - Create the test cases in AIO Tests that you intend to automate and copy test case keys we will need them on step 3.

Step 2 - Open your IDE and install this npm package. It adds the AIO Tests Playwright Reporter, which links your Playwright test results to AIO Tests automatically.

npm install aiotests-playwright-reporter

Step 3 - In Step 1, you copied the AIO Tests case key. Now, include it in your test title using the '@' symbol. This acts as a Playwright tag and helps AIO match the test with the correct test case.

test("@PAT-TC-3: Verify that user can add items to the cart", async ({
  page,
  purchasingPage,
  locators,
}) => {
  const PurchasingLocators = locators.Purchasinglocators;
  await purchasingPage.AddItemsToCart();
  await expect(page.locator(PurchasingLocators.Cart)).toContainText("2");
});

Step 4 - Add the following configuration outside the default function in your Playwright config file. Each key helps define how your test results are reported to AIO Tests.

In the next steps, we'll store AIO_API_KEY and JIRA_PAT as GitHub Actions secrets. That's why we reference them as environment variables, so they can be securely injected into the workflow at runtime.

const aioConfigDetails = {
  enableReporting: true, // ✅ Set to true to report test results to AIO Tests (default is false)
  jiraProjectId: "PAT", // ✅ Jira project key where the AIO test cases are managed
  cloud: {
    apiKey: process.env.AIO_API_KEY, // ✅ API key for AIO Cloud, stored securely as an environment variable
  },
  server: {
    jiraServerUrl: "https://yourorgname.atlassian.net/", // ✅ Jira base URL (used only for Jira Server setup)
    pat: process.env.JIRA_PAT, // ✅ Personal Access Token for Jira Server, pulled from environment variable
  },
  cycleDetails: {
    createNewCycle: "false", // ✅ Options: [true, false, "CREATE_IF_ABSENT"]
    // Set to true to always create a new test cycle for this run

    cycleName: "PAT-Test-Cycle-1", // ✅ Used when createNewCycle is true
    // Sets the name for the new test cycle being created

    cycleKey: "PAT-CY-2", // ✅ Used when createNewCycle is false
    // Links the run to an existing cycle by its key
  },

  addAttachmentToFailedCases: true, // ✅ Adds only screenshots to failed test cases if available
};

Configuration Details

Jira Project ID

The first three letters of an AIO test case key usually represent your project ID, but if you're unsure, you can find the project ID on the Project Settings page in Jira.

To get the AIO API Key

Go to AIO Tests in your project → Click the gear icon on the navigation bar → Select My Settings from the dropdown options → Choose the API Token option from the side navigation → Generate a new API token and keep the token safe until you add it as a secret to your repository.

Jira Server URL

You can find your Jira Server URL directly from the browser's address bar when you are logged into your Jira instance.

Jira Personal Access Token

Click the gear icon next to your Jira profile image in Jira → Select "User Management" option at the bottom of the list → Switch to "Settings" tab → Select "API Key" option from side navigation → Create an API token and keep the token safe until you add it as a secret to your repository.

Refer to the documentation to see the full list of supported parameters you can pass.

Step 5 - Add the reporter with the AIO config object as shown below; this configures the AIO Tests reporter with the required aioConfig settings.

reporter: [
  ["aiotests-playwright-reporter", { aioConfig: aioConfigDetails }], // List reporter for console output
],

Step 6 - In your GitHub workflow file, add the following under env:

env:
  AIO_API_KEY: ${{ secrets.AIO_API_KEY }}
  JIRA_PAT: ${{ secrets.JIRA_PAT }}

This makes your AIO API key and Jira PAT token available as environment variables during the workflow run. It allows your Playwright config to securely access them from GitHub Secrets via environment variables (process.env), without exposing the actual values in your code or logs.

Step 7 - Add AIO API key and Jira PAT as repository secrets.

Go to GitHub repo → Switch to "Settings" → Expand "Secrets and Variables" dropdown → Select "Actions" options → Click "New Repository Secrets" button and add AIO API key and Jira PAT.

Note - When adding secrets, make sure the naming conventions are consistent and match exactly where they are referenced in your code or workflows.

Before setting up AIO Tests to trigger workflows directly from the AIO Tests interface, run the workflow manually to verify whether the test cases are being updated correctly after the workflow execution.

As you can see, we've configured aioConfig to create a new cycle and update the test case statuses, so after the workflow run, a new cycle was created and the test cases were successfully updated.

🪄 Triggering GitHub Actions Workflows via the AIO Tests Interface

Step 8

In this step, the CI/CD system is configured by selecting a hosting platform such as GitHub:

Click the "CI" button in the tool ribbon.
Click the "Setup CI/CD" system button
Select "GitHub" as the system type and choose the version (personal accounts are always under "GitHub Cloud").
Enter a name for your CI/CD system.
Enter your GitHub username and click the "Save" button.

Step 9

Now that the CI/CD workflow is configured, the next step is to define a job within the workflow to execute the actions:

Click the "View Job" icon on the created CI/CD system.
Click the "Configure New Job" button.
If this is your first time, you'll be prompted to enter a GitHub API token. To do this, generate one from your GitHub account, paste it, and click "Save".
Provide a name for the job, add a description, and enter the repository name.
Click the "Search" button. If the repository name is correct, the list of branches and workflows will be displayed.
Add any job parameters, if required.
Under Authentication, choose one of the three available options based on your preference.
Once everything is configured, click the "Save" button.
To trigger the job, select the job you want to run, click the "Play" icon, and then click the "Trigger" button.

Now that everything is set up, a test cycle was created from the AIO Tests interface, and the aioConfig was updated accordingly:

cycleDetails: {
  createNewCycle: "false", // ✅ Options: [true, false, "CREATE_IF_ABSENT"]
  // Set to true to always create a new test cycle for this run

  cycleName: "PAT-Test-Cycle-1", // ✅ Used when createNewCycle is true
  // Sets the name for the new test cycle being created

  cycleKey: "PAT-CY-2", // ✅ Used when createNewCycle is false
  // Links the run to an existing cycle by its key
},

An assertion was intentionally altered to fail a test case, to verify that failed test cases and their attachments are updated correctly.

🔚 Conclusion

This article explains how to integrate GitHub Actions with AIO Tests to trigger Playwright test workflows directly from the AIO Tests interface. With this setup, you can effortlessly manage and run your Playwright tests through AIO Tests, ensuring efficient execution and accurate reporting.

Performance Testing 101: Understanding the Basics of Performance Testing

Ramesh Lakmal — Tue, 30 Dec 2025 14:38:58 GMT

1. Understanding Software Testing Types

Software testing is mainly divided into two types: functional testing and non-functional testing.

Functional testing checks what a system or component should do. It ensures that all features work correctly, completely, and appropriately.
Non-functional testing focuses on how well the system performs. It evaluates software quality aspects like performance, compatibility, usability, reliability, security, maintainability, and portability (as defined by the ISO/IEC 25010 standard).

Non-functional testing can begin early in the development cycle, such as during code reviews or system testing. It often builds on functional tests by verifying additional conditions, like how fast a function runs or whether it works on different platforms. Detecting non-functional issues late can seriously impact a project’s success, as some tests require specialized environments, like usability labs.

2. What is Performance Testing

Performance testing checks how well an application works under different conditions, like high user traffic, large amounts of data, or slow networks. It ensures the system is fast, stable, scalable, and responsive. Since performance testing falls under non-functional testing, it focuses on how the system behaves rather than what it does.

For example, imagine testing a new highway before opening it to the public. Engineers check if it can handle heavy traffic, extreme weather, and different vehicle weights to ensure it’s safe and reliable. Similarly, performance testing ensures an application can handle real-world usage without slowing down or crashing.

3. Why Performance Testing Matters

Performance testing is crucial because a slow, unstable, or unresponsive application can lead to frustrated users, lost revenue, and a damaged reputation. In today’s fast-paced digital world, users expect websites and apps to load quickly and function smoothly. Even a few seconds of delay can cause users to leave and switch to competitors.

3.1 Cost of Poor Performance

Lost Users & Revenue - Poor performance has lasting financial impacts. Research shows that 88% of users won’t return after a bad experience, and for e-commerce sites, a one-second delay can cost millions in lost sales. Losing loyal customers and acquiring new ones adds to the cost, making performance issues even more expensive over time
Brand Damage - A brand’s reputation is tightly linked to the performance of its digital products. A slow, buggy, or unreliable application can quickly create a negative perception, and in today’s interconnected world, bad experiences spread fast. Social media amplifies complaints, turning small issues into viral stories that can damage trust and drive potential customers away. Once a brand gains a reputation for poor performance, it can be difficult to shake it off.
When Your App Fails, Competitors Win - Performance issues on your app aren’t just a technical issue; it’s an open invitation for competitors to step in. The moment your service goes down, rivals seize the opportunity to attract frustrated users with a smoother, more reliable experience. Whether through targeted marketing or simply being the more dependable option, they position themselves as the better choice, making it even harder for your brand to regain lost trust.

4. What Are the Types of Performance Testing?

4.1 Load Testing – Can the system handle expected traffic?

Load Test

Load testing evaluates how a system performs under typical conditions, such as the average number of users or requests it is expected to handle. The goal is to verify that the application can maintain performance levels and function correctly when operating within normal, expected usage patterns.

Example - Imagine you run an e-commerce website, and you expect a surge in traffic during a big sale event. To ensure your website performs well under high demand, you conduct load testing by simulating 400 concurrent users accessing your site at the same time

4.2 Stress Testing – What happens when we push beyond limits?

Stress Test

Stress testing involves pushing the system to its breaking point by increasing the load until the system fails or experiences performance degradation. The aim is to identify the system’s maximum capacity and understand how it handles extreme conditions.

Example - Testing a web application by simulating 1000 users when it is designed for only 500 users to see how it crashes or recovers.

4.3 Spike Testing – Can the system handle sudden traffic bursts?

Spike Test

Spike testing is a type of stress testing where the system is subjected to sudden, extreme spikes in user traffic. It measures the system’s ability to cope with quick surges in demand and checks how it recovers after the spike.

Example - Simulating a sudden traffic spike on an online store during a flash sale and verifying if the system can handle the surge without crashing.

4.4 Soak Testing – Does the system remain stable over time?

Soak Test

Soak testing, also known as endurance testing, involves running the system under a normal or heavy load for an extended period to identify issues like memory leaks, database slowdowns, or performance degradation over time

Example - Running a database server under moderate load for 48 hours to identify memory leaks or performance issues that may not be visible during short-term testing.

Conclusion

Performance testing is crucial for ensuring applications remain fast, stable, and reliable under varying loads. It helps detect performance bottlenecks before they impact users, preventing slowdowns, crashes, and revenue loss. By incorporating performance testing into the development process, businesses can deliver seamless digital experiences and maintain customer trust.

In the next article, we’ll explore k6, a powerful performance testing tool, and cover its basics to help you get started.

Building with PostgreSQL - The Slotted Counter Pattern

Pasindu Pramodya — Tue, 16 Dec 2025 07:56:29 GMT

If you've ever built applications like a blog platform or quiz app, you've probably encountered the need for keeping track of some kind of counter, whether that's a blog post comment count, a like count, or quiz app answer counts. Pretty simple, right? But have you ever wondered how to scale such a simple thing? What happens if thousands of people try to update the counter? Today, we're going to build such an application and scale our way to the top.

Traditional Approach

Sample App

Let's build an app first. Our app is a simple quiz app. Here are the requirements just for our use case:

The app has a UI to display questions, and the user can submit an answer.
Internally, we verify the answer and keep track of two key things: the total answer count and the correct answer count.
We use both the total answer count (A) and the correct answer count (C) to calculate a difficulty score.
The difficulty score algorithm will look like this:

 $difficulty=1- \frac{C}{A}$

$C$ = correct count

$A$ = total attempts

In the end, this calculation will yield a value that looks something like 0.41.

Building the Application

We're not going to focus on the backend or the frontend; we're only focused on the database. To showcase this use case, we'll need three tables:

answers table
questions table
answer_stats table

When a user answers a question, we'll insert a record into the answers table. Based on the answer, we'll then update the answer_stats table. The required database structure will look like this:


CREATE TABLE IF NOT EXISTS "answers" (
	"id" UUID NOT NULL UNIQUE,
	"answer" TEXT NOT NULL,
	"student_id" UUID NOT NULL,
	"question_id" UUID,
	PRIMARY KEY("id")
);

CREATE TABLE IF NOT EXISTS "questions" (
	"id" UUID NOT NULL UNIQUE,
	"content" TEXT,
	PRIMARY KEY("id")
);

CREATE TABLE IF NOT EXISTS "answer_stats" (
	"question_id" UUID UNIQUE,
	"total_attempts" BIGINT,
	"total_success" BIGINT,
	PRIMARY KEY("question_id")
);

ALTER TABLE "answer_stats"
ADD FOREIGN KEY("question_id") REFERENCES "questions"("id")
ON UPDATE NO ACTION ON DELETE NO ACTION;
ALTER TABLE "answers"
ADD FOREIGN KEY("question_id") REFERENCES "questions"("id")
ON UPDATE NO ACTION ON DELETE NO ACTION;

To test our inserts, we can add a question and answers with transactions.

Insert a Question


INSERT INTO questions (id, content)
VALUES (gen_random_uuid(), 'What is 2 + 2?');

Add Answer Stats with Transactions (Initial, Hot-Row Approach)


DO $$
DECLARE

q_id UUID := '2adf2d89-d7c5-4fa8-b0e8-087d3c137715'; -- generated id from question.change this 
BEGIN

-- Step 1: Insert a new answer linked to that question

INSERT INTO answers (id, answer, student_id, question_id)
VALUES (
gen_random_uuid(),
'4',
gen_random_uuid(),
q_id
);

-- Step 2: Update or insert into stats

INSERT INTO answer_stats (question_id, total_attempts, total_success)
VALUES (
q_id,
1,
floor(random() * 2)::int -- 0 or 1
)
ON CONFLICT (question_id)
DO UPDATE

SET

total_attempts = answer_stats.total_attempts + 1,
total_success = answer_stats.total_success + floor(random() * 2)::int;
COMMIT;
END $$;

This does work, but why is this a performance bottleneck?

There are many reasons why this is not a good solution, including:

Frequent writes to the same rows
Random writes +ON CONFLICT overhead
MVCC history
Transactional cost

We are focusing on one issue here: why Frequent writes to the same rows are bad. To answer this question, we need to understand how PostgreSQL handles writes.

If many users answer the same question, every transaction tries to update the same row. That means every transaction competing to update the same row in answer_stats

To sum it up:

PostgreSQL must take a row-level exclusive lock during each update.
Only one transaction can update that row at a time, and others get queued up.
This creates a "hot row" and causes contention, latency, and deadlocks.

So now we know why this is bad. But is there any better way to do this? Of course. Divide and Conquer.

The Slotted Counter Pattern

What is This Slotted Counter Pattern anyway?

Instead of storing counts in a single row, we split the count into multiple rows called slots. Each slot is an independent counter that we update randomly. When we need to increment a counter, we randomly pick one of these slots to update.

Think of it like having multiple checkout counters at a grocery store instead of one. Sure, you need to add up all the registers at the end of the day, but customers flow through much faster.

Here's the beautiful part: with 10 slots, we can handle 10 concurrent updates to the same answer stats with zero contention. Our throughput increases $10$ x, and response times drop back to normal.

Redesign

Instead of one row per question, now we are going to create multiple slots:


-- drop the old table 
DROP TABLE IF EXISTS "answer_stats";

CREATE TABLE IF NOT EXISTS "answer_stats" (
"question_id" UUID,
"total_attempts" BIGINT,
"total_success" BIGINT,
"slot_number" SMALLINT NOT NULL
);
ALTER TABLE "answer_stats"
ADD FOREIGN KEY("question_id") REFERENCES "questions"("id")
ON UPDATE NO ACTION ON DELETE NO ACTION;

ALTER TABLE "answer_stats"
ADD CONSTRAINT unique_question_per_slot UNIQUE (question_id, slot_number);

\nWhen updating, we randomly select a slot and update it.


DO $$
DECLARE

q_id UUID := '2adf2d89-d7c5-4fa8-b0e8-087d3c137715'; -- generated id from question

BEGIN

-- Step 1: Insert a new answer linked to that question
INSERT INTO answers (id, answer, student_id, question_id)
VALUES (
gen_random_uuid(),
'4',
gen_random_uuid(),
q_id
);

-- Step 2: Update or insert into stats
INSERT INTO answer_stats (question_id, total_attempts, total_success, slot_number)
VALUES (
q_id,
1,
floor(random() * 2)::int, -- 0 or 1

ceil(random() * 10) -- Assign a random slot number between 1 and 10
)
ON CONFLICT (question_id,slot_number)
DO UPDATE

SET

total_attempts = answer_stats.total_attempts + 1,
total_success = answer_stats.total_success + floor(random() * 2)::int;
COMMIT;
END $$;

Finally, when we want to calculate total attempts and success, we sum up the values using the question ID.

When NOT to Use This Pattern

Low-traffic counters: Less than 10 updates/second? Just use a single row.
Strong consistency requirements: Need real-time exact counts? This adds eventual consistency
Simple applications: Don't optimize prematurely

Use this pattern when you have clear evidence of contention, not as a default.

Alternative Approaches

Before implementing slotted counters, consider these alternatives:

Application-level caching: Batch updates in your app, flush periodically
Redis counters: Offload to an in-memory store
PostgreSQL unlogged tables: Faster writes, but data lost on crash
Queue-based updates: Use a message queue to serialize writes

Each has trade-offs around consistency, complexity, and durability.

Final Implementation Checklist

Start small: Begin with 10 slots per partition
Monitor slot distribution: Use pg_stat_activity to spot hot slots
Benchmark: Simulate load with pgbench before production

Conclusion

The Slotted Counter Pattern is a powerful technique for scaling high-frequency counters in PostgreSQL. By distributing writes across multiple rows, you can:

Eliminate lock contention
Maintain accuracy through aggregation
Scale to thousands of updates per second
Keep your database schema simple

Remember: Start simple, optimize when needed. Monitor your database performance, and reach for slotted counters when you have concrete evidence of contention.