Building a Fault-Tolerant Node.js Backend: 4 Patterns I Applied to My Ticketing App

Shahin Quliyev — Fri, 24 Apr 2026 19:38:50 +0000

While building iTicket.AZ — a real-time event ticketing platform — I came across a job posting from a major bank that listed "building scalable, resilient, and fault-tolerant applications" as a core requirement. That made me think: is my backend actually fault-tolerant? Spoiler: it wasn't. Here's what I changed.

What does "fault-tolerant" actually mean?

A fault-tolerant system keeps running — even in degraded form — when parts of it fail. That means your app doesn't crash just because the database hiccuped, a third-party API timed out, or a job queue backed up. There are four patterns I focused on.

Pattern 1 — Retry + Circuit Breaker

When a DB write fails, should we silently drop it? No — but we also shouldn't hammer a broken service forever. The retry pattern tries again a few times; the circuit breaker stops calls entirely after too many failures.

import CircuitBreaker from 'opossum';

const dbOptions = {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
};

const breaker = new CircuitBreaker(saveTicketToDB, dbOptions);

breaker.fallback(() => ({
  success: false,
  message: 'Service temporarily unavailable. Try again shortly.'
}));

export const createTicket = async (data) => {
  return await breaker.fire(data);
};

Now instead of hanging requests, your users get a clean error immediately. Library: opossum.

Pattern 2 — Graceful Degradation

If the chat service (Socket.IO) goes down, should ticket purchasing stop too? Absolutely not. Each feature should fail independently.

export const getEventDetails = async (eventId: string) => {
  const [event, chatStatus] = await Promise.allSettled([
    EventService.findById(eventId),
    ChatService.getStatus(eventId),
  ]);

  return {
    event: event.status === 'fulfilled' ? event.value : null,
    chatAvailable: chatStatus.status === 'fulfilled',
  };
};

Promise.allSettled is the key here — unlike Promise.all, it doesn't throw if one promise rejects.

Pattern 3 — Health Checks + Structured Logging

app.get('/health', async (req, res) => {
  const checks = {
    database: await checkDB(),
    uptime: process.uptime(),
    timestamp: new Date().toISOString(),
  };
  const allOk = Object.values(checks).every(Boolean);
  res.status(allOk ? 200 : 503).json(checks);
});

const log = (level: string, message: string, meta = {}) => {
  console.log(JSON.stringify({
    level, message, ...meta,
    service: 'iticket-api',
    ts: new Date().toISOString(),
  }));
};

Pattern 4 — Queue + Async Processing

import Queue from 'bull';

const emailQueue = new Queue('ticket-emails', process.env.REDIS_URL);

export const purchaseTicket = async (req, res) => {
  const ticket = await TicketService.create(req.body);
  await emailQueue.add({ ticketId: ticket.id, userEmail: req.body.email });
  res.status(201).json({ success: true, ticket });
};

emailQueue.process(async (job) => {
  await EmailService.sendConfirmation(job.data);
});

Even if your main server crashes after responding, Bull will re-run the job when it comes back up.

The result

These four patterns transformed iTicket.AZ from a "works on my machine" project into something I'd actually put in front of an interviewer. The concepts map directly to what enterprise teams look for when they say "scalable, resilient, and fault-tolerant."

GitHub: https://github.com/sahin4367/iTicket.AZ

🚨 Real-time Traffic & Crime Safety Alerts Agent (n8n + Bright Data + OpenAI + Google Maps)

Shahin Quliyev — Sun, 31 Aug 2025 07:26:53 +0000

For the Real-Time AI Agents Challenge powered by n8n and Bright Data, I built a project that sends real-time safety alerts about traffic accidents and crimes directly to users’ emails.

Problem

People often learn about traffic accidents and crimes too late.

This creates risks in terms of both safety and fines.

Solution

Workflow pulls real-time data from Google News every 30 minutes (via Bright Data).
OpenAI shortens and improves the news.
If a location is found, a Google Maps link is added.
The final alert is sent to the user via email.

Demo

Watch the demo video here :
https://drive.google.com/file/d/18OrqMucTJih3-L5R5m6LSKF59cvlTQW0/view?usp=sharing

Explore the workflow on GitHub :
https://github.com/sahin4367/Real-time-Traffic-Crime-Safety-Alerts-Agent

Advantages

Reduced risk of fines and accidents
Protects people's safety
Easy to implement and expand

Workflow :

E-mail Inbox :

Google Maps link :

“This agent is not just a technology demonstration – it can save lives and create real value to improve safety.”

devchallenge #ai #webdev #n8nbrightdatachallenge #brigthdata #devto #workflow #openai #n8n #hashaton #dev

DEV Community: Shahin Quliyev

[Boost]