DEV Community: Gaurav Singh

Scaling the Data Layer in Distributed Systems

Gaurav Singh — Fri, 26 Dec 2025 12:18:47 +0000

Scaling a stateless system is relatively straightforward. We can horizontally scale application servers by adding more instances behind a load balancer, and the system continues to work as expected.

But what happens to the database?

How can a database running on a single machine handle requests coming from N horizontally scaled application servers? Databases must scale too — and this is where things get interesting.

The First Idea: Replication
A natural first thought is:

“Let’s just replicate the database and create multiple copies.”

At first glance, this sounds reasonable. But the moment we try to scale traditional SQL databases using replication, we run into fundamental constraints.

Why SQL Databases Don’t Scale Easily
SQL databases are built around powerful guarantees:

Joins across tables
Cross-row and multi-table transactions
Global constraints (foreign keys, unique keys, auto-increment IDs)
All of these assume one critical thing:

All data lives in one logical place.

Once we attempt to shard or distribute SQL data:

Joins turn into cross-network calls
Transactions span machines
Locks stop working globally
As a result:

Complexity explodes
Performance degrades
Application logic becomes significantly more complex
This doesn’t mean SQL cannot be sharded — it can — but doing so safely requires heavy coordination and careful design.

The Leader–Follower Model
To improve scalability, many systems move to a leader–follower replication model.

Press enter or click to view image in full size

How It Works
A single leader (primary) accepts all writes
Followers (replicas) copy data from the leader
Reads may be served from followers to scale read traffic
This gives us:

One source of truth for writes
Multiple copies for read scaling and fault tolerance
But a key question remains:

How does the leader propagate writes to followers?

The answer lies in replication strategies.

Replication Strategies in Leader–Follower Systems

Strong Consistency (Synchronous Replication) In this model:

The leader writes data locally
The leader waits for acknowledgements from a quorum (majority) of replicas
Only then does it respond to the client
This ensures:

Strong consistency
No stale reads (when reads also use quorum or leader)
Tradeoffs:

Higher write latency
Reduced availability if replicas are slow or unavailable
Importantly, strong consistency does not require waiting for all followers — waiting for a majority is sufficient.

Eventual Consistency (Asynchronous Replication) Here:

The leader writes data locally
It sends replication messages to followers
It responds to the client without waiting for most acknowledgements
This model:

Improves write latency and throughput
Allows reads from followers to return stale data temporarily
Relies on the system eventually converging
This is a deliberate tradeoff:

Availability and performance over immediate consistency

The Leader Bottleneck Problem
Even with replication, a fundamental limitation remains:

All writes still go through a single leader.

As write QPS grows (e.g., 10K+ writes per second):

The leader becomes a bottleneck
CPU, I/O, and replication overhead increase
Vertical scaling eventually hits limits
At this point, simply adding more replicas doesn’t help — because replicas don’t accept writes.

This is where partitioning (sharding) becomes necessary.

The Entry of NoSQL

NoSQL databases emerged to solve exactly this problem:
scaling writes and reads horizontally at massive scale.
Key motivations behind NoSQL systems:

High write throughput
High availability
Fault tolerance
Geo-distribution
Low latency at scale
Rather than optimizing purely for normalization and storage efficiency, NoSQL systems are designed to scale by default.

Sharding in NoSQL Databases
NoSQL databases distribute data using sharding.

How Sharding Works
A partition (shard) key is chosen (e.g., user_id)
The key is hashed or range-mapped
Data is distributed across shards
Each shard owns a mutually exclusive subset of data
Common partitioning strategies:

Consistent hashing
Range-based partitioning (A–G, H–M, etc.)
Choosing the correct shard key is critical:

A poor shard key can cause hotspots and destroy scalability.

Replication Inside a Shard
Each shard is still replicated for fault tolerance.
This is where two NoSQL replication models appear.

Model 1: Leader–Follower per Shard
Used by systems like:

MongoDB
DynamoDB
HBase
Per Shard:
One leader
Multiple followers
Write Flow:
Client routes request to shard leader
Leader writes data
Leader propagates to followers
Leader waits for:
Quorum acknowledgements (stronger consistency), or
Minimal acknowledgements (eventual consistency)
Read Flow:
Reads may go to leader (fresh)
Or followers (faster, possibly stale)
This model is simple and efficient but still has:

Leader hotspots
Leader failover complexity
Model 2: Quorum-Based (Leaderless) Replication
Used by systems like:

Cassandra
Riak
Dynamo-style designs
Per Shard:
No leader
All replicas are equal
Write Flow:
Client sends write to any replica (coordinator)
Coordinator sends write to all replicas
Write succeeds when W replicas acknowledge
Read Flow:
Client reads from R replicas
Latest version wins
Inconsistencies are repaired in the background
This model:

Avoids leader bottlenecks
Improves availability
Requires conflict resolution and versioning
Quorum Explained (Simply)

Let:

N = total replicas per shard
W = replicas required to acknowledge a write
R = replicas required for a read
Rules:

Strong consistency: R + W > N
Eventual consistency: R + W ≤ N
Examples:

Banking, inventory → strong consistency
Social feeds, likes, analytics → eventual consistency
Quorum decisions are made per shard, not globally.

Final Takeaway

SQL databases struggle with horizontal write scaling due to strong global guarantees
Leader–follower replication improves read scaling but not write scaling
NoSQL databases solve this by sharding data ownership
Each shard scales independently
Replication within shards is handled using leader-based or quorum-based models
Consistency is a configurable tradeoff, not a fixed property
Modern data systems don’t ask “Can we scale?” — they ask “What consistency are we willing to trade for scale?”

Hey Team, Do check out this awesome doc for building E2E Distributed Job Scheduler!

Gaurav Singh — Sat, 24 May 2025 13:34:39 +0000

Gaurav Singh

May 24 '25

Building a Distributed Job Scheduler: End2End Design

#systemdesign #backend #interview #aws

Comments

3 min read

Building a Distributed Job Scheduler: End2End Design

Gaurav Singh — Sat, 24 May 2025 13:33:49 +0000

In today's software systems, many applications need to execute background tasks—at scale, reliably, and at the right time. This blog post covers a comprehensive system design for a Distributed Job Scheduler, diving deep into functional/non-functional requirements, high-level design, storage choices, idempotency, queue processing, and integration with tools like AWS SQS and Kafka.

🔧 Functional Requirements

Users can submit jobs/tasks to run on a particular schedule.
Support for manual triggering of jobs.
Jobs are Python scripts (support for other languages can be added later).
At-least-once execution of scheduled jobs.
Recurring jobs with enable/disable mechanisms.
Job sequencing support: Job1 -> Job2 -> Job3

📈 Non-Functional Requirements
High availability.

At-least-once execution of jobs.
Job runs must happen on or close to schedule (2-4s delay acceptable).
Durability: no job should be lost even if system crashes.
Delay notifications to users.
Scalability to 10 billion jobs/day.

📊 Throughput & Storage Estimations
Throughput: 10⁹ jobs/day → ~10⁴ jobs/sec
Storage: Assuming 200 lines/job, 50 bytes/line, Total: 200 * 50 * 10⁹ = 10 TB/day for job binaries

🏗️ High-Level Design
🔹 API Design
POST /api/v1/jobs

{
  "taskId": "someUniqueId",
  "cron": "*/5 * * * *",
  "params": {
    "p1": "val1",
    "p2": "val2"
  }
}

GET

/api/v1/jobs/:jobId

Returns job status.

🧠 Database Considerations
Since the system is write-heavy, choose NoSQL stores like DynamoDB, Cassandra, or MongoDB.

Writes:

Create job
Record job run
Update status Reads:

Poll jobs due in the next minute (configurable)
Sort and enqueue

❌ Why not SQL?
No normalization required.
ACID guarantees not critical.

Sample Schema

{
  "time_bucket": "2025-05-24T10:00:00Z",
  "execution_time": "2025-05-24T10:00:05Z",
  "job_id": "job_abc_123",
  "user_id": "user_123",
  "status": "PENDING",
  "attempt": 0,
  "script_url": "s3://bucket-name/path-to-script.py"
}

🔄 Scheduling & Execution Flow

WatcherService polls DB every minute (via a CronJob or periodic ECS task).
Picks jobs for next 1-min window.
Pushes to FIFO SQS Queue.
ExecutorService pulls from SQS.
Spawns isolated ECSContainer to run each job securely.
Performs idempotent check.
Executes and updates DB.

🧾 Sequence Diagram - LLD

✅ Handling Duplicate Events (Idempotency)
Problem:
If the ExecutorService crashes mid-execution or fails before DeleteMessage, SQS redelivers the message.

Solution:
Implement idempotency by checking if jobRunId is already processed before executing:

if (jobRunId already in DB with status SUCCESS) {
   // Skip processing
} else {
   // Execute and update DB
}

📬 FIFO SQS Acknowledgement Workflow

ReceiveMessage: Executor polls for messages.
Visibility Timeout starts.
If successfully processed → DeleteMessage() → removes from queue.
If not deleted within timeout → message is re-queued.

Yes, the consumer must explicitly delete the message. This applies to all SQS-based systems.

🧪 Java Boilerplate (SQS FIFO Consumer)

AmazonSQS sqs = AmazonSQSClientBuilder.defaultClient();
String queueUrl = "https://sqs.us-east-1.amazonaws.com/your-queue-url";

ReceiveMessageRequest request = new ReceiveMessageRequest()
    .withQueueUrl(queueUrl)
    .withWaitTimeSeconds(10)
    .withMaxNumberOfMessages(1);

while (true) {
    List<Message> messages = sqs.receiveMessage(request).getMessages();
    for (Message msg : messages) {
        String body = msg.getBody();
        // Deserialize and process

        // Idempotency check here

        // Delete after successful execution
        sqs.deleteMessage(queueUrl, msg.getReceiptHandle());
    }
}

🔁 How Kafka Handles This?
Kafka is different from SQS:

Kafka does not auto-delete messages.
Consumers commit offsets manually.
To prevent duplication, maintain idempotency checks (e.g., jobRunId).

ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
    if (!jobAlreadyProcessed(record.key())) {
        process(record.value());
        markJobComplete(record.key());
    }
}
consumer.commitSync();

🧠 What is Idempotency?
A process is idempotent if running it multiple times has the same effect as running it once.

Example in Job Scheduler:

If a jobRunId is already marked as completed, skip execution.
This ensures safe reprocessing in case of retries.

📈 Metrics & Monitoring (Enhancement Ideas)
Execution Metrics:

Jobs submitted/executed per minute/hour/day
Average execution time
Error/Success ratio

Infrastructure Health:

CPU/Memory usage for Executor nodes
Queue size (SQS/Kafka lag)
DB read/write latency

Alerts & Dashboards:

Set up alarms for job delays, failures, or high retry count
Use tools like Prometheus + Grafana or AWS CloudWatch

Dead Letter Queues (DLQ):

For jobs that fail after multiple retries

Audit Logs:

Log job submissions, execution attempts, and results
Store in Elasticsearch or S3 for analysis

📌 Final Thoughts
This blog outlines the complete design of a scalable, reliable distributed job scheduler with real-world production-grade strategies:

Durable job ingestion
Idempotent execution
FIFO queue management (SQS)
Resilience with AWS services
Extendable to Kafka or other Pub/Sub platforms
Ideas for metrics, monitoring, and alerting integration

Thanks for reading! I share insightful Real World System Designs and DSA patterns every week. Follow for high-quality, actionable content that will level up your skills!

Follow me for more such posts: https://www.linkedin.com/in/gauravsingh9356/

Building a Scalable Real-Time Ticket Queue System - BookMyShow

Gaurav Singh — Mon, 14 Apr 2025 22:15:47 +0000

Modern ticketing platforms like BookMyShow and DISTRICT handle massive traffic spikes (100k+ users) while maintaining fairness and real-time updates. This guide explores how to architect such a system using WebSockets, Redis, and a scalable backend.

📌 Problem Statement & Requirements
When selling limited tickets for high-demand events (concerts, festivals), we need:

✔ Massive Scalability – Handle 100k+ concurrent users.
✔ Fair Queueing – First-come-first-served (FCFS) using a real-time queue.
✔ Resilience – Survive server crashes, network issues.
✔ Real-Time Updates – Users see their live position in the queue.
✔ Purchase Notifications – Alert users when it's their turn to buy.

🏗 System Architecture Overview
🔹 Core Components

Client (Web/Mobile) – Connects via WebSocket for real-time updates.
Load Balancer (NGINX, AWS ALB) – Distributes WebSocket connections.
WebSocket Servers (Node.js, Go, etc.) – Maintain live connections.
API Server (REST/GraphQL) – Handles ticket purchases.
Redis – Manages queue (Sorted Set) and Pub/Sub for real-time sync.

Sequence Diagram - LLD
Let's understand the whole flow with the help of sequence diagram:

Explaining the Sequence Diagram (Detailed Full Lifecycle Flow)
This sequence diagram represents a complete lifecycle of a user joining the queue, getting updates in real time, buying a ticket, and how the system maintains synchronization across multiple servers.

Let's break it down step by step:

👤 1. User Connects to Queue via WebSocket

A user opens the app or website and initiates a WebSocket connection.
The Load Balancer (e.g., NGINX, AWS ALB) routes this connection to one of the WebSocket servers (WS).

➕ 2. User is Added to the Queue in Redis

The WebSocket server adds the user to the sorted set (ZADD) in Redis.
Additionally, it stores a mapping of user to server (HSET socket_clients) for monitoring/debugging (optional).

✅ 3. User Receives Confirmation & Position

Redis acknowledges the insert.
The server calculates the user's rank in the queue (ZRANK) and sends the initial position to the user.

🔁 4. Periodic Heartbeat (Health Check)

Client sends periodic ping messages to keep the connection alive.
Server responds with pong. This prevents timeout and helps detect disconnections.

🎟️ 5. User Buys a Ticket via API

User clicks “Buy Ticket”.
The API (can be same as WS or separate) removes them from the queue using ZREM.
Publishes an event via PUBLISH to the queue_update_channel in Redis.

📢 6. Redis Pub/Sub Broadcasts to All Servers

All WebSocket servers are subscribed to queue_update_channel.
They receive the published message (userA-left) and act accordingly.

📬 7. Servers Calculate and Send Updated Queue Positions

After someone leaves the queue, everyone behind them needs a new position.
Each WebSocket server queries Redis (ZRANK) for the latest positions of their connected users.
Sends updates via WebSocket.

🧹 8. Cleanup After Leaving
Once the user leaves or buys the ticket, we remove their socket mapping (optional).

🤝 Server-to-Server Communication (Why This Works)

Servers don’t talk to each other directly — instead:
All servers are subscribers to the same Redis Pub/Sub channel.
When a queue change happens (buy/leave), a message is published to Redis.
Redis broadcasts it to all subscribers (all WS servers).
Each server reacts

🚀 Benefits of This Architecture

No tight coupling between servers.
Highly scalable — just add more WS servers.
Single source of truth (Redis).
Can easily recover from failure (via reconnect + Redis state).

🔌 Deep Dive: Key Mechanisms
1️⃣ Redis Data Structure (Sorted Set - ZSET)

ZADD concert_queue
ZRANK concert_queue → Returns position (0 = first).
ZREM concert_queue → Removes user after purchase.

✅ Why Sorted Set?

O(log N) time complexity for inserts/removals.
Atomic operations prevent race conditions.
2️⃣ WebSocket Flow (Real-Time Updates) Client-Side Connection

const socket = new ReconnectingWebSocket("wss://tickets.example.com/queue");

socket.onopen = () => {
  socket.send(JSON.stringify({ 
    type: "join_queue", 
    userId: "user123", 
    authToken: "Bearer xyz" 
  }));
};

socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.type === "position_update") {
    console.log(`Your position: ${data.position}`);
  }
};

Server-Side Handling

const WebSocketMap = new Map(); // userId → WebSocket

wss.on("connection", (socket) => {
  socket.on("message", async (msg) => {
    const { type, userId } = JSON.parse(msg);

    if (type === "join_queue") {
      WebSocketMap.set(userId, socket);
      const position = await redis.zrank("concert_queue", userId);
      socket.send(JSON.stringify({ type: "position_update", position }));
    }
  });
});

3️⃣ Pub/Sub for Cross-Server Sync
When a user buys a ticket (or leaves), we remove them from the queue and notify all servers:

// API Server (after ticket purchase)
await redis.zrem("concert_queue", userId);
await redis.publish("queue_updates", JSON.stringify({ 
  event: "user_left", 
  userId 
}));

// All WebSocket Servers (subscribed)
redis.subscribe("queue_updates");
redis.on("message", (channel, msg) => {
  const { event, userId } = JSON.parse(msg);
  if (event === "user_left") {
    // Recalculate & broadcast positions
    WebSocketMap.forEach(async (socket, userId) => {
      const position = await redis.zrank("concert_queue", userId);
      socket.send(JSON.stringify({ type: "position_update", position }));
    });
  }
});

Let's Understand it by going one step more deeper

🔌 WebSocket Flow (Client ↔️ Server)

Client Connects to WebSocket

const socket = new WebSocket("wss://ticket.com/ws");
socket.send(JSON.stringify({ type: "join", userId: "userA" }));

Server Handles Connection

wss.on("connection", (socket) => {
  socket.on("message", async (msg) => {
    const data = JSON.parse(msg);
    if (data.type === "join") {
      WebSocketMap.set(data.userId, socket);
      const position = await redis.zrank("concert_queue", data.userId);
      socket.send(JSON.stringify({ type: "queue_update", position }));
    }
  });
});

Queue Position Update (Purchase or Leave)

// Example: userB buys ticket
await redis.zrem("concert_queue", "userB");

// Publish event
redis.publish("queue_update_channel", JSON.stringify({ userId: "userB" }));

Pub/Sub Broadcasting Every server listens:

redis.subscribe("queue_update_channel");

redis.on("message", async (channel, msg) => {
  const data = JSON.parse(msg);
  // broadcast to all WebSocket clients
  WebSocketMap.forEach(async (socket, userId) => {
    const position = await redis.zrank("concert_queue", userId);
    socket.send(JSON.stringify({ type: "queue_update", position }));
  });
});

🧩 Handling Edge Cases
🔴 1. WebSocket Server Crashes
Problem: In-memory WebSocketMap is lost.

Solution:

Clients auto-reconnect using ReconnectingWebSocket.
On reconnect, server re-fetches position from Redis.

🔴 2. Client Disconnects (Network Issues)
Solution:

Heartbeat checks (ping/pong).
If no response for 30s, remove from queue:

await redis.zrem("concert_queue", userId);
redis.publish("queue_updates", JSON.stringify({ userId }));

🔴 3. Redis High Availability
Solution:

Use Redis Cluster + Persistent Storage.
Fallback to database-backed queue if Redis fails.

⚡ Scaling Strategies
Component Scaling Approach

WebSocket Servers -> Horizontal scaling + sticky sessions.
Redis -> Sharding (if queue exceeds memory).
API Servers -> Stateless, auto-scaling (Kubernetes).

✅ Final Architecture - FlowChart Diagram

🚀 Conclusion
This architecture ensures:

✔ Real-time queue updates via WebSockets.
✔ Scalability with Redis + horizontal scaling.
✔ Resilience against crashes and disconnects.

Used by: DICE, DISTRICT, Ticketmaster’s virtual queues.

*What are Next Steps - *

Add rate limiting to prevent abuse.
Implement priority queues (e.g., premium users).
Use Kubernetes for auto-scaling.

This is how we can make scalable, reliable and maintable real time artitechtures where we can handle millions of traffic!

Read this far ? hope you liked the article 😊 Yes ? Give the thumps Up! and leave your feedback. It gives me motivation to write more and share with the community!

LinkedIn: https://www.linkedin.com/in/gauravsingh9356/

J.A.R.V.I.S Crossed 700+ 🌟 Stars and 160+ Forks on GitHub!

Gaurav Singh — Mon, 18 Dec 2023 07:08:32 +0000

Hello Everyone 👋 , Excited to share that 𝐉.𝐀.𝐑.𝐕.𝐈.𝐒 have crossed more than 700+ ⭐ and 160+ forks on GitHub. It was the project developed by me during my first year of my college. Being my first project, it remains very special to me, it feels so unreal and wonderful to know work you have done, getting so much love.

What it does...

Dynamic Authentication using Optical Face Recognition
Send emails
Dynamic News Reporting at any time with api integration
Todo list generator, Yes it remembers all!
Open any website with just a voice command
Plays Music

Tells time
Wikipedia powered AI
Dictionary with Intelligent Sensing i.e. auto checking if spell mistake
Weather Report such as temp, wind speed, humidity, weather description

Latitude and longitude
YouTube searching
Google Map searching
YouTube Downloader, download any youtube video by just putting url of video

Now Master can switch b/w J.A.R.V.I.S and F.R.I.D.A.Y, switch to female voice assistant

This shows how great and big open source is. I am working to make it even bigger. Will share some more new features very soon.

Thanks to Everyone who have made their valuable contributions ❤.

Ownership - It's Importance in Software Engineering

Gaurav Singh — Tue, 10 Oct 2023 14:48:44 +0000

A good software engineer's most important skill is ownership

Ownership is one thing I've learnt by hustling in startups!

And ownership doesn't just means to get the job done! 🙅‍♂️

Its about treating the product as your own, not just thinking about its development, but how you can improve the architecture, how can you improve the performance, and also how can you improve the product as a whole!

Thinking about new features.
Thinking about improving user experience.
Thinking about increasing user retension!

I love the Amazon's "Customer Obsession" principle, I truly believe it's one of the most important principle which separates good engineers from great one's!

One tip to improve your "Product Engineering" skills: Remove the concept of tech & implementation from your head before you think about a product, don't think about how complex it will be, is it feasible or not, just think about the best product you can!

Everything can be built by great engineers :)

🌟 Sharing My Exciting 6-Month Internship Journey at Amazon! 🎉

Gaurav Singh — Sun, 03 Sep 2023 18:36:19 +0000

I am thrilled to share that today marks the end of an incredible chapter in my professional journey! Over the past six months, I have had the privilege of being a part of an amazing team and gaining invaluable experience as an SDE Intern at Amazon 🚀.

From day one, I was warmly welcomed into the company and immersed in a dynamic and collaborative work environment. During my internship, I had the opportunity to work on a variety of challenging projects that allowed me to apply my skills and knowledge in practical ways. ✨

From conducting market research to assisting with project management, every task presented new learning opportunities and helped me sharpen my abilities.

As I reflect on these past six months, I am filled with a profound sense of growth and accomplishment. The challenges I faced have helped me develop resilience and problem-solving skills, which I know will serve me well in my future endeavors.

Let's Connect!
LinkedIn: https://www.linkedin.com/in/gauravsingh9356/
Github: https://github.com/gauravsingh9356
Twitter: https://twitter.com/GauravS36826604

🔥 600+ 🌟 and 140+ Forks to J.A.R.V.I.S 🚀, Added Dynamic Face Recognition to J.A.R.V.I.S 🤖

Gaurav Singh — Sun, 14 May 2023 14:07:26 +0000

J.A.R.V.I.S (Just A Rather Very Intelligent System)

New Feature: Dynamic Face Recognition

What it does...

Dynamic Authentication using Optical Face Recognition
Send emails
Dynamic News Reporting at any time with api integration
Todo list generator, Yes it remembers all!
Open any website with just a voice command
Plays Music
Tells time
Wikipedia powered AI
Dictionary with Intelligent Sensing i.e. auto checking if spell mistake
Weather Report such as temp, wind speed, humidity, weather description
Latitude and longitude
YouTube searching
Google Map searching
YouTube Downloader, download any youtube video by just putting url of video
Now Master can switch b/w J.A.R.V.I.S and F.R.I.D.A.Y, switch to female voice assistant

[GitHub Code](https://github.com/GauravSingh9356/J.A.R.V.I.S

Future Plans:
Sky is limit. There are immense possibilities in this project. Will be integrating some very powerful commands soon..

Contribution:

Thank you for your interest in contributing to our Repo! Pull requests are welcome. For adding new feature or improving structure or fixing typos, please make a PR with your fixes. We are happy for every contribution. A lot can be done with this project. Core AI chatbot like functionality can be added. More python scripts can be associated. Pull requests for any such changes are accepted. Feel free to fork this project and make your own changes too.

J.A.R.V.I.S Crossed 500+ 🌟 Stars and 130+ Forks on GitHub!

Gaurav Singh — Sun, 07 May 2023 13:17:51 +0000

Hello Everyone 👋 , Excited to share that 𝐉.𝐀.𝐑.𝐕.𝐈.𝐒 have crossed more than 500+ ⭐ and 130+ forks on GitHub. It was the project developed by me during my first year of my college. Being my first project, it remains very special to me, it feels so unreal and wonderful to know work you have done, getting so much love.

This shows how great and big open source is. I am working to make it even bigger. Will share some more new features very soon.

Thanks to Everyone who have made their valuable contributions ❤.

https://lnkd.in/eJWnaEk

And We DID IT! || J.A.R.V.I.S Reached 400+ 🌟 and 100+ forks || GauravSingh9356

Gaurav Singh — Wed, 26 Jan 2022 16:02:26 +0000

Hi All! 👋
This is a appreciation post to all the open source lovers out there, J.A.R.V.I.S has now crossed over 400+ ⭐ and 100+ forks on GitHub. I am overwhelmed with this amazing response.

If you have not checked it please check it out once, I promise this will be one of the amazing beginner project that will take your python skill to NEXT Level!. You will understand how cool things you can make with python!

Recently I have added Optical Text Recognition (OCR) with it.

GitHub Link

Again Big THANKS!
Gaurav Singh

SEMESTER PROJECT DEMO

Gaurav Singh — Sun, 01 Aug 2021 15:51:28 +0000

Hello All,
Hope all of you are doing well!. I have completed my 4th semester and in which I have developed a real world Tour Management project. Demo can be seen here.
Youtube Link

GitHub
Plss don't forget to leave your comments and feedback!
Cheers!

Real Time Face Mask Detection || Tensorflow || OpenCV

Gaurav Singh — Wed, 09 Jun 2021 17:41:13 +0000

Hello, Devs! Worked on CNN model to detect a masked face. The model is currently working with an accuracy of 98.537%. Working on it to improve its accuracy further.

𝐍𝐞𝐭𝐰𝐨𝐫𝐤 𝐮𝐬𝐞𝐝 : 𝐂𝐨𝐧𝐯𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐚𝐥 𝐍𝐞𝐮𝐫𝐚𝐥 𝐍𝐞𝐭𝐰𝐨𝐫𝐤
𝐅𝐚𝐜𝐞 𝐃𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧: 𝐇𝐚𝐚𝐫-𝐜𝐚𝐬𝐜𝐚𝐝𝐞
𝐅𝐫𝐚𝐦𝐞𝐰𝐨𝐫𝐤 𝐮𝐬𝐞𝐝: 𝐓𝐞𝐧𝐬𝐨𝐫𝐟𝐥𝐨𝐰
𝐀𝐏𝐈 𝐮𝐬𝐞𝐝: 𝐊𝐞𝐫𝐚𝐬
𝐂𝐨𝐦𝐩𝐮𝐭𝐞𝐫 𝐕𝐢𝐬𝐢𝐨𝐧 𝐥𝐢𝐛𝐫𝐚𝐫𝐲 𝐮𝐬𝐞𝐝 : 𝐎𝐩𝐞𝐧𝐂𝐕
𝐓𝐞𝐬𝐭𝐢𝐧𝐠 𝐕𝐢𝐝𝐞𝐨: https://lnkd.in/dk7ad9a

GitHub