Skip to content
Back to projects
07 2024
Automation Full-Stack

AutoMgsWeb — Automação WhatsApp

WhatsApp messaging automation platform integrated with the ERP.

databases integrated
3
hash-based queue idempotency
SHA-256

From pain to result

Fig. 07 — Data flow 8 nodes · 7 edges
MongoDB PostgreSQL SQL Server (UAU) Flask Queue + worker hash-based idempotency Recipient resolution cached WhatsApp API WhatsApp
Store Application Process External Output
01

Before

Communication with clients and partners was manual, with no standard and no central history.

Communication with customers and partners was manual, with no standardization or centralized history.

02

How · 1/3

I built a Flask application that orchestrates sending through the WhatsApp API, resolving the correct recipient identifier with caching, and cross-referencing data from MongoDB, PostgreSQL and SQL Server (UAU).

03

How · 2/3

Every message originates from a real business trigger coming out of the ERP — this is not bulk blasting, it is the operation notifying whoever needs to know.

04

How · 3/3

The system is midway through a deliberate migration: the scheduler embedded in the legacy app is being replaced by a PostgreSQL queue with separate scheduler and worker, and the new queue guarantees idempotency via SHA-256 hashing. Both modes coexist in production while the swap happens.

05

After

Every message comes from a real ERP trigger — not a mass blast, but operations notifying whoever needs to know.

3
databases integrated
SHA-256
hash-based queue idempotency

Reading the diagram

Polyglot architecture: three databases of different natures converge into a single application. Between the app and the send there are two steps most people skip — the queue, which prevents re-sends, and recipient resolution, without which the message vanishes without an error.

Technical highlights

  1. 1 Recipient-identifier resolution before sending, with caching — it is what separates a delivered message from one lost in the void.
  2. 2 Polyglot architecture: MongoDB (legacy), PostgreSQL (new queue) and SQL Server (ERP) in the same application.
  3. 3 Queue idempotency via SHA-256 hashing: reprocessing a batch never re-sends a message to the customer.
  4. 4 Incremental migration with both modes coexisting, rather than a big-bang rewrite of a system already in production.