DEV Community: Shahin Quliyev

We have 8 billion people connected online, so why is genuine global networking dying? (An Open Invitation)

Shahin Quliyev — Mon, 01 Jun 2026 19:19:37 +0000

Hey Dev.to community! 🌍

I’ve been thinking about a weird paradox lately, and I want to know if it’s just me, or if you feel it too.

We live in the most interconnected era of human history. We have high-speed internet, GitHub, Discord, and countless social networks. Technically, I can reach someone on the other side of the planet in less than a second.

Yet, genuine, mission-driven networking is dying.

Our current platforms (LinkedIn, Twitter, etc.) are built around profiles and personal branding. They force us into corporate bubbles. If I am a backend dev in Azerbaijan, why is it so hard for me to naturally team up with a frontend student in Germany, a designer in France, or an engineer in Sweden to solve a real-world problem? Why do we only meet during chaotic 48-hour hackathons and then never speak again?

I want to change this. I don't want us to connect based on "job titles." I want us to connect based on Problems.

💡 The Idea: Problem-Centric Networking
I am building a global platform where students and early-stage developers from completely different cultures, backgrounds, and countries don't just "match"—they unite around shared real-world issues.

Whether it's Agri-Tech, Smart Cities, Climate tech, or workflow automation, the platform’s algorithm will match you into a Cross-Border Team based on the problem you are passionate about solving, not just your tech stack.

You don't just build a project; you experience a true cultural and intellectual exchange.

🚀 The MVP Stage: Looking for the Pioneers
Before writing the heavy backend code, I want to validate the human element of this. I am running a manual MVP pilot program to see how we can bridge these gaps.

I am looking for the first 20-30 developer students and creators (especially from Europe and across the globe) who are tired of building generic Todo apps and want to tackle real-world problems in international teams.

Who I’m looking for:
Developers (Backend, Frontend, Fullstack) who want to collaborate globally.

UI/UX Designers who want to see their ideas come to life.

Problem-solvers who care about sustainability, smart infrastructure, or open-source tools.

What we will do together:
I will manually match you into a small, international team based on your interests.

We will provide a structured space to brainstorm, design, and prototype a solution.

You’ll get to experience working across different time zones, languages, and cultures—exactly like a global remote startup.

💬 Let’s Talk!
If you are a student or developer in Europe (or anywhere else!) and you feel lonely in your local tech bubble, this is your sign to break out.

Drop a comment below with:

Where you are from 📍

Your main tech stack/skill 🛠️

One global or local problem you really care about (e.g., green energy, urban mobility, tech education) 🧠

OR if you want to join the MVP pilot immediately, fill out this quick form: sahin43g@gmail.com , https://www.linkedin.com/in/shahin-quliyev-43lrkd/

Let's stop networking for resumes, and start networking for impact. 🚀

How I built a fault-tolerant Node.js backend — Docker, HashiCorp Consul, and GitHub Actions

Shahin Quliyev — Sat, 25 Apr 2026 12:10:25 +0000

I was working on iTicket.AZ — a backend service for real-time event ticketing, built with Node.js and TypeScript — when I came across a job posting at a major bank. Their requirement: "build scalable, resilient, and fault-tolerant applications."

I looked at my own backend and asked honestly: is this fault-tolerant? The answer was no. The server had no health awareness, no service discovery, no restart policy, and no automated build verification. This post is about exactly what I fixed — with real code from the project.

Problem 1 — The backend had no health awareness

When the database went down, the backend kept accepting HTTP requests and silently failing all of them. No signal to any external system.

app.get("/api/v1/health", async (_req, res) => {
  const dbOk = await AppDataSource.query("SELECT 1")
    .then(() => true)
    .catch(() => false);

  res.status(dbOk ? 200 : 503).json({
    status: dbOk ? "healthy" : "degraded",
    checks: {
      database: dbOk ? "up" : "down",
      uptime: Math.floor(process.uptime()),
    },
    service: "iticket-api",
    timestamp: new Date().toISOString(),
  });
});

A 200 means everything is working. A 503 means the service is alive but impaired. Any infrastructure tool — Consul, a load balancer, Kubernetes — can now make routing decisions based on this response.

Problem 2 — No service discovery

Even with a health endpoint, nothing was calling it. HashiCorp Consul polls /api/v1/health every 10 seconds. If it receives a 503, it marks the instance critical and deregisters it after 30 seconds — automatically.

async function registerWithConsul(): Promise<void> {
  try {
    await consulClient.agent.service.register({
      name: "iticket-api",
      address: "api",
      port: Number(appConfig.PORT),
      check: {
        name: "iticket-api health",
        http: `http://api:${appConfig.PORT}/api/v1/health`,
        interval: "10s",
        timeout: "3s",
        deregistercriticalserviceafter: "30s",
      },
    } as any);
  } catch (err) {
    // Non-fatal — app starts normally in local dev without Consul
    console.warn("Consul registration skipped:", err);
  }
}

The try/catch is intentional. Making the registration failure non-fatal is itself a fault-tolerance decision: the monitoring layer going down should not take the application with it.

Problem 3 — A single crash meant a permanent outage

services:
  api:
    build: .
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_HOST: postgres

  postgres:
    image: postgres:16-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DB_USERNAME} -d ${DB_NAME}"]
      interval: 10s
      retries: 5
    restart: unless-stopped

  consul:
    image: hashicorp/consul:1.18
    ports:
      - "8500:8500"
    restart: unless-stopped

PostgreSQL must pass its own health check before the API starts. If the API crashes, Docker restarts it. Consul monitors it continuously.

Problem 4 — Broken builds reached the repository undetected

name: iTicket.AZ CI
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm install typescript --save-dev
      - run: npx tsc --noEmit
      - run: npx tsc

  docker:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t iticket-api:${{ github.sha }} .

How the pieces connect

git push
  → GitHub Actions: type check + Docker build
      ↓ passes
  → docker-compose up
      PostgreSQL → health check passes
      ↓ healthy
      iticket-api → registers with Consul
      ↓
      Consul polls /api/v1/health every 10s
        503 → marks critical → deregisters after 30s
        crash → Docker restarts automatically

A health endpoint is useless without something polling it. Consul is useless without something to register with it. A restart policy is useless if the app starts before the database is ready. The pieces only become fault-tolerant as a system when they are connected.

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

[Boost]

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

Shahin Quliyev

Apr 24

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

#node #backend #architecture #typescript

2 min read

🚨 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