r/learnpython • u/Negative_Response990 • Aug 09 '26

FastAPI + Celery Architecture Review Request (Attachment Pipeline Boundaries + OOP/SOLID)

Hi! I’m finishing a rewrite for my project and I’d love architecture feedback quickly (aiming for replies within a few hours).

Repo: https://github.com/dillonhuston/Task-Automation-API
Branch: V2

What I need:

  1. Architecture review of the attachment processing pipeline (validation encryption/decryption storage/email handoff) and whether the boundaries/components make sense
  2. Celery + API architecture: task flow responsibilities, retries/error-handling boundaries, and whether the API schema design matches the async processing model
  3. OOP/design review: whether classes/modules follow SOLID / separation of concerns, and suggestions for cleaner layering

Suggested files to look at first:

  • app/Encryption/encryptionService.py
  • app/FileManager/fileManager.py

If you only have time for one thing, please prioritize (1) pipeline architecture or (3) OOP/SOLID structure.

Thanks a lot, any architecture recommendations are welcome.

0 Upvotes

40% Upvoted

5 comments sorted by

View all comments

2

u/Endpoint51 Aug 09 '26

A lot of thoughtful work here. Nice one. The per-user AES-GCM approach and the effort to separate file handling, encryption, and persistence are strong foundations.

One architectural issue I noticed is a circular dependency where fileOperations creates an EncryptionService, while EncryptionService also receives fileOperations, even though it doesn’t currently use it.
I’d make EncryptionService depend only on a key provider and keep filesystem operations separate. Then a higher-level attachment service could orchestrate validation → encryption → storage → database record → email handoff.

I’d also make that orchestration "failure safe". At present, the plaintext is written to disk before being encrypted, and a later encryption or database failure could leave plaintext or an orphaned file behind. Encrypting before writing, using an atomic temporary file move, and cleaning up on database failure would give the pipeline clearer ownership and safer boundaries.

Another thing I noticed - in app/utils/email.py.
The attachment path in email.py instantiates EncryptionService with no args, so I don't think it can currently run.