DEV Community

Cover image for My Learning Journey: Factory Pattern, Encryption (AES), and PostgreSQL Database Design
Bharath Kumar_30
Bharath Kumar_30

Posted on

My Learning Journey: Factory Pattern, Encryption (AES), and PostgreSQL Database Design

Today was a really productive day in my project journey. I focused on understanding some important backend concepts that are actually used in real-world applications. I worked on three main areas:

  • Factory Pattern (Design Pattern)
  • Encryption (AES vs Hashing)
  • PostgreSQL Database Design (DDL + Structure)

I’ll explain everything in a simple and practical way based on what I learned.


🧠 1. Understanding Factory Pattern

At first, I was confused about why we need a factory when we already have routers. But now it’s clear.

What is Factory?

Factory is just a helper function that creates the correct object based on input.

Instead of writing multiple if-else conditions everywhere, we centralize object creation in one place.

My Use Case

In my project, I support multiple platforms like:

  • Telegram
  • Twitter
  • Instagram
  • Reddit

Each platform has its own service class.

Instead of doing this:

if platform == "telegram":
    service = TelegramService()
elif platform == "twitter":
    service = TwitterService()
Enter fullscreen mode Exit fullscreen mode

I used a factory:

def get_service(platform_name, credentials):
    REGISTRY = {
        "telegram": TelegramService,
        "twitter": TwitterService,
        "instagram": InstagramService,
    }

    service_class = REGISTRY.get(platform_name.lower())
    return service_class(credentials) if service_class else None
Enter fullscreen mode Exit fullscreen mode

Why this is better?

  • Cleaner code
  • Easy to maintain
  • Easy to add new platforms
  • No repeated logic

Final understanding

Factory = dynamically create the correct service object based on platform


πŸ” 2. Encryption vs Hashing (AES Explained)

This was another important concept I learned today.

Hashing

  • One-way process
  • Cannot reverse
  • Used for passwords

Example:

password -> hashed value
Enter fullscreen mode Exit fullscreen mode

We never get the original password back.


Encryption (AES)

  • Two-way process
  • Can encrypt and decrypt
  • Used for sensitive data like API keys

Why I used AES?

In my project, I store credentials like tokens and API keys.

These values need to be used later, so I cannot use hashing.

That’s why I used encryption.


What is AES?

AES is a symmetric encryption algorithm.

That means:

Same key is used for:

  • Encryption
  • Decryption

Simple Flow

Original Data -> Encrypt using key -> Encrypted Data
Encrypted Data -> Decrypt using same key -> Original Data
Enter fullscreen mode Exit fullscreen mode

Key Point

If the key is lost, data cannot be recovered.


πŸ—„οΈ 3. PostgreSQL Database Design

Today I also designed my database using PostgreSQL.

What is DDL?

DDL stands for Data Definition Language.

It is used to define database structure.

Examples:

  • CREATE TABLE
  • ALTER TABLE
  • DROP TABLE

My Database Structure

I designed a clean and scalable structure with multiple tables.


1. Users Table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(100),
    email VARCHAR(150) UNIQUE,
    password TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
Enter fullscreen mode Exit fullscreen mode
  • Stores user data
  • Password is hashed
  • Email is unique

2. Platforms Table

CREATE TABLE platforms (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE
);
Enter fullscreen mode Exit fullscreen mode
  • Stores platform names
  • Easy to scale (add new platform without changing code)

3. User Credentials Table

CREATE TABLE user_platform_keys (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    platform_id INT REFERENCES platforms(id),
    encrypted_data TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE(user_id, platform_id)
);
Enter fullscreen mode Exit fullscreen mode
  • Stores API keys (encrypted)
  • Prevents duplicate platform connection
  • Deletes data if user is deleted

4. Posts Table

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id),
    content TEXT,
    status VARCHAR(20) CHECK (status IN ('pending', 'processing', 'sent', 'failed', 'partial')),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
Enter fullscreen mode Exit fullscreen mode
  • Stores user posts
  • Status is controlled using CHECK constraint

5. Post Logs Table

CREATE TABLE post_logs (
    id SERIAL PRIMARY KEY,
    post_id INT REFERENCES posts(id) ON DELETE CASCADE,
    platform_id INT REFERENCES platforms(id),
    status VARCHAR(20),
    error_message TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
Enter fullscreen mode Exit fullscreen mode

Why separate logs?

One post can be sent to multiple platforms.

Example:

  • Telegram -> Success
  • Twitter -> Failed

So logs are stored separately to track each platform result clearly.


🎯 Final Thoughts

Today I understood how real backend systems are designed.

  • Factory pattern helps in clean and scalable architecture
  • AES encryption helps in securing sensitive data
  • PostgreSQL schema design helps in structured and reliable data storage

This learning helped me move from basic coding to thinking like a backend developer.


πŸ“Œ Key Takeaways

  • Don’t mix logic in router β€” use factory
  • Use hashing for passwords, encryption for reusable secrets
  • Always design database with scalability and constraints
  • Separate logs for better tracking and debugging

This was a great learning day for me. More improvements coming soon.

Top comments (0)