Design a web service for asynchronous communication.
Asynchronous Communication :
Developing a system that allows a client to submit a request without having to wait for the server to reply right away with the outcome. This is helpful in situations where processing takes a long time, like sending emails or processing images.
Key APIs:
1. POST /job: Send in a request
The client provides input data (such as a file or job details).
Answer: 202 Accepted + job_id
2. GET /job/{job_id} - Verify the status of the job Response:
Awaiting
Inprocess
Finished with the URL for the result
Failed.
3. (Optional) GET /result/{job_id} Fetch result: Provides a download link or processed data.
Resume Parser Tool
A resume is uploaded by the user (POST /job).
The server queues the parsing task and returns the job ID.
To check the status, the user polls GET /job/{job_id}
After finishing, the user obtains the parsed data from GET /result/{job_id}.
We are developing a service in which:
A user submits a request, such as uploading a file.
"You got it!" the system says. I'll notify you when it's finished.
To view the outcome, the user returns later (or receives a message).
Consider placing an order at a food truck:
You submit your request or order.
"We'll call your number when it's ready," the chef says, handing you a token.
You wait close by or your phone pings.
You pick up your order when it's ready.
You're not waiting at the counter until it's finished because this communication is asynchronous.
Step by Step :
The user submits a job → "This file is attached. Kindly process it. → "Okay, your job ID is 123," the system responds.
It is added to the queue by the system. Similar to a bakery line ticket
The worker takes up the task and gets to work on it. It could take a few seconds or several minutes.
The user uses the job ID to check their status. "Is my order ready yet?"
After finishing, the user receives the following message: "Your file has been processed." To download, click this link.
Email Order Confirmation
On an online store, you place an order.
The system processes your order and sends a confirmation email a few seconds later, rather than waiting for the email to show up right away.
While this is taking place in the background, you can continue to browse.
Why async?
We don't want the user to be stuck on the checkout screen, and email delivery can take a few seconds.
✅ SMS Customer Service
When the support staff is available, the user texts a question and receives a response. It's asynchronous because there's no need to wait on hold.
✅ Scheduling or Verifying an Appointment
A user can text "YES" or confirm a time slot. After processing it, the system reacts if necessary. It's asynchronous and not live.
✅ Product Requests for Neighborhood Companies
A prospective customer may email with inquiries regarding availability, color, or size. When someone is free, the store responds. It's async once more.
✅ Event RSVP through SMS
A brief response such as "I'm coming" or "+2 guests" is sent by the user. The system either logs it or confirms it. Everything takes place in the background.
✅ Receive Deals or Discounts
The system responds with a coupon code when the user inputs a keyword, such as "SAVE10." It's an automated, asynchronous exchange with no live representative involved.
✅ Order Monitoring
A tracking request is sent via SMS by a user. Shortly after, the system looks it up and responds. It's also async because they aren't waiting on a live agent.
✅ Feedback Gathering
The user texts their rating or thoughts. Later, it is reviewed or stored. No real-time conversation is taking place.
✅ Emergency Number
When a user sends a message, the system escalates it internally, even in emergency situations. Technically, the response is still asynchronous because it still requires some processing.
High-Level Components
Usually, you'll need the following to create an asynchronous web service:
Client (User App): Here, users can upload files or request reports, among other tasks.
After receiving the request, API (The Front Desk) provides the user with a Job ID so they can check back at a later time.
For instance: "Thanks! We are processing your request. ID for the job: 123
The task queue, also known as the waiting line, holds all incoming jobs until a worker is available to process them.
Consider it the system's to-do list.
Worker (The Real Doer): A background service retrieves tasks from the queue and finishes them, such as sending an email or processing a file.
Every job, its status (pending, processing, completed), and the outcome are all recorded in the database (The Tracker).
Notification System (Optional): When a task is finished, users can receive an email, SMS, or dashboard notification.
Useful Technologies
You don't have to start from scratch. You can make use of:
A web framework, such as Express.js, FastAPI, or Flask, that manages requests
A job-holding queue system, such as Amazon SQS, Redis Queue, or RabbitMQ
A worker tool for job processing, such as Sidekiq, Celery, or a basic script
A job status database, such as Redis or PostgreSQL
An optional alert system such as Webhooks, Twilio, or SendGrid
