by Nishant.
Workspace/Projects/Notification System
Built in the open
All projects
ASYNC PROCESSING / CASE STUDY

Notification System

Separate order requests from email delivery.

Backend development · Rust + RedisImplemented · personal project
RustRedisSMTP
WHERE THIS CREATES VALUE

Demonstrates the separation of a user-facing request from slower background work such as confirmation emails.

01 / CONTEXT

The problem

Sending email directly in an order handler couples the request to an external SMTP dependency. A queue introduces a boundary between accepting an order and delivering a notification.

02 / IMPLEMENTATION

The approach

A Rust API validates an order and pushes an email job to Redis. A separate worker removes jobs from the queue, builds a confirmation email, and sends it through SMTP.

  • Order API with recipient and order input validation
  • Serialized email jobs pushed to a Redis queue
  • Separate SMTP worker with delivery logging
  • Shared Rust workspace and environment-based configuration
03 / ARCHITECTURE

Follow the flow.

Select a stage to explore its role. This diagram explains the documented design; it is not live infrastructure.

ARCHITECTURE EXPLORERDOCUMENTED DESIGN
STEP 1 / 4

Order request

POST /orders accepts order details and a recipient address.

04 / TRADEOFFS

The decisions behind it.

Move the slow dependency out of the handler

A worker owns SMTP delivery while the API owns request validation and job creation.

Use an explicit job boundary

A serialized EmailJob is the contract between the API process and worker process.

Keep scope visible

Queueing demonstrates asynchronous processing. It does not by itself establish durable order storage, safe retries, or exactly-once delivery.

05 / EVIDENCE

What the evidence supports.

The README documents Cargo tests and an SMTP verification procedure using a controlled mailbox or capture service. No real email was sent as part of building this portfolio, and no delivery reliability rate is claimed.

Current boundaries

  • Orders are stored in memory rather than a durable order database.
  • The documented flow does not establish retry, acknowledgement, or dead-letter guarantees.
  • A worker log or queue acceptance is not proof that a recipient read the message.
06 / NEXT STEPS

What comes next.

  • Introduce durable order persistence and a recoverable job acknowledgement design.
  • Define idempotency, retry limits, and failed-job reconciliation before production use.
Read the project documentation
NEXT CASE STUDYZenPlay