DEV Community: Artak Matiniani

Scaling Async Tasks in Django with Celery & Redis: The Human Side of a Technical Challenge

Artak Matiniani — Fri, 11 Jul 2025 10:29:15 +0000

I still remember the moment my Django app hit a brick wall.

A user would click Submit, and then… silence. Nothing happened. The entire interface froze, like an awkward conversation that goes nowhere, while the server chugged along trying to process file uploads and data imports synchronously.

It was painful. And it was absolutely unsustainable.

Every heavy operation was blocking the entire user experience. There was no way I could scale, no way I could keep growing, if every new user had to wait for the server to finish before getting their feedback.

That was my breaking point — the moment I realized I needed to offload these heavyweight tasks to the background. I had heard of Celery and Redis, and I decided to take the plunge.

The Fear Factor

Let’s be honest: adding Celery and Redis to your stack for the first time is terrifying.

I was worried I’d break everything. I’d built core features that kind of worked, and here I was about to introduce two new moving parts, layering on a message broker, a worker, background queues. It felt like balancing on a tightrope while holding flaming swords.

What if my logic failed?
What if I had to rebuild the entire architecture from scratch?
What if I broke the one thing that was at least working?

That fear is real — and if you’re reading this in the same spot, please know you’re not alone.

My Hardest Lesson: The Memory Leak Weekend

If there’s one moment burned into my brain, it’s the memory leak weekend.

I was processing large datasets inside Celery tasks but forgot to clean up my database connections properly. At first, everything ran beautifully. But a few hours later, Redis started hitting its memory limits, and the entire system crashed like a house of cards.

I felt overwhelmed, exhausted, and honestly a bit defeated.

It took a full weekend of relentless debugging, staring at task logs, restarting containers, until I finally tracked down the missing cleanup. The lesson was harsh but unforgettable:

Async is not just about moving code to the background.
It’s about thinking differently — especially around resource management and observability.

A Moment of Pride

I’d be lying if I said it was all horror stories, though.

There was this amazing moment when I finally got my async file processing pipeline humming. Users could upload large files, get immediate feedback, and see a progress bar updating in real-time while continuing to use other parts of the app.

No freezing. No endless spinning wheel of doom.

It was a huge personal victory. It proved to me that I could design, build, and ship a scalable architecture, even if it was way outside my comfort zone at first.

One Bit of Advice

If you’re a junior dev about to add Celery to your Django project, please:

👉 Start small. Don’t try to async-ify everything at once.
👉 Pick one simple, slow operation (email sending is perfect) and move just that to Celery.
👉 Set up monitoring tools like Flower on day one.
👉 And absolutely design for graceful failures — tasks will fail, and you need to communicate that clearly to users.

The async architecture is only as strong as its failure handling.

The Human Takeaway

In the end, this challenge taught me something about, not just about technology.

I discovered that I’m incredibly patient and persistent when I believe in something. Even after hours of frustration, I kept showing up because I genuinely cared about making this work for my users.

That’s probably the best lesson of all:
When you care deeply about what you’re building, you’ll find a way to keep pushing forward, no matter how many memory leaks or broken queues stand in your way.

If you’re on the fence about async, or you’re terrified of adding Celery, know this: it is scary. But it’s also empowering. It will make you a better, more resilient developer, and it will unlock performance and user experience wins you never thought possible.

Stay curious. Stay humble. And keep moving forward — even if you break things a few times along the way.

🩺 How I Built MedicOS to Reduce Drug Errors

Artak Matiniani — Sat, 05 Jul 2025 11:26:47 +0000

Ever since I left medicine to become a developer, I dreamed of building something that could help doctors and patients at the same time. MedicOS is that dream taking shape.

In Georgia, many patients see doctors too late — with advanced conditions that require multiple medications. This means doctors must juggle polypharmacy, and even the best doctors can struggle to catch every drug interaction.

That’s where MedicOS comes in.

What is MedicOS?
It’s a Django-based medication safety assistant that checks for drug interactions using OpenFDA, suggests alternatives, and reminds patients to take their medications through text or voice messages. I wanted patients to stay on track, and doctors to prescribe more confidently.

API integrations
One of the biggest wins was integrating with OpenFDA. They offer a huge amount of structured data, which made building the drug safety checks much faster. Storing patient medication lists securely was also crucial — PostgreSQL gave me a solid, reliable backend for this.

Voice reminders with Polly
I learned that many elderly patients struggle with text reminders. So I used AWS Polly to generate voice messages. That was my first time working with async Python — sending messages and transcribing them without blocking the system. It was a mind-expanding moment, even if a bit scary at first.

What I learned about data structure and flow
MedicOS taught me how critical it is to keep the data simple and predictable. From normalizing drug entries, to mapping side effects, to handling multilingual voice instructions — every layer had to flow seamlessly. PostgreSQL schemas, Django models, and message queues all had to align.

Was it hard?
Of course — I’m human, and the bugs were relentless. But every bug taught me something.

How I feel
Pride. Pure pride. Watching MedicOS come alive and do exactly what I imagined feels incredible. It wasn’t stressful — it was a pleasure. I got to blend my medical knowledge with my engineering skills and create something that might, one day, actually save lives.

👉 If you could automate one thing in healthcare, what would it be? I’d love to hear your ideas — maybe they’ll spark my next project.

How I Built ScrapeFlow AI: End-to-End AI Automation for Content Creators

Artak Matiniani — Mon, 30 Jun 2025 10:58:39 +0000

“The measure of intelligence is the ability to adapt.” - Einstein

When I started working on ScrapeFlow AI, I wasn’t personally tired of posting content every day - but I realized a lot of people are. Content creators, founders, and marketers spend hours scheduling and publishing the same types of posts again and again. That’s a perfect candidate for automation.

Inspired by Einstein’s quote above, I wanted to build something that would help people adapt - and free up their time for more meaningful work. ScrapeFlow AI became a proof-of-concept that showed me how powerful software can be: you can have an idea today, and make it real with some reading, experimenting, and a bit of courage.

⸻

Tech Stack: Django, Celery, Redis, DeepSeek

I chose Django because I feel comfortable with MVC frameworks, and Django lets you seamlessly work on every aspect of your application.

This was actually my first time using Celery and Redis - but I’m happy with how quickly I learned. Celery handled the asynchronous background tasks, while Redis acted as the broker.

For AI-driven content generation, I experimented with DeepSeek. Initially I tried to run a local version to keep the costs at $0, but even when calling the API, it was extremely affordable - only about $0.08 for nearly two months of use!

⸻

Challenges and Lessons

One of the hardest parts was fine-tuning the AI prompts. Every time I changed something in the post-creation logic (like tweaking the tone), I had to restart and rebuild the entire Docker container. Sure there were painful moments - but breaking down the work into small steps and celebrating each new feature kept me motivated.

If I had more time, or a team, I’d love to add things like image generation and more advanced post design. But I’m happy with v1. There weren’t really any “obvious in hindsight” mistakes, which feels good.

⸻

What I’d Do Next

ScrapeFlow AI showed me that the possibilities in the dev world are endless. I’d absolutely expand it with more features if I worked on it again, especially richer post-creation with visuals.

⸻

See It in Action

🎥 YouTube Demo: https://youtu.be/Pf5N3wnn1hA?si=OF4txfscTfuKm7v9
💻 GitHub Repository: https://github.com/ArtTheAche98/ScrapeFlowAI

⸻

If you’re a content creator spending hours manually scheduling posts — take a look at ScrapeFlow AI. Automate, adapt, and focus on the work that matters most.

Why I Left Medicine for Software Engineering

Artak Matiniani — Sat, 28 Jun 2025 16:22:37 +0000

Ever since grade five, I knew I wanted to become a doctor. I even wrote an essay about it - and I still keep it to this day. By the time I graduated, my classmates had signed my farewell shirt with “House MD” printed across the back. That should tell you how fully I’d embraced the dream.

For years, I chased that goal with everything I had. I put in the hours, the effort, the late nights, determined to help people and make an impact.

But somewhere along the way, something shifted.

It wasn’t that I stopped caring. In fact, maybe I cared too much. The system I was in made it hard to care without burning out. Good work often went unnoticed. There was little room to breathe, to grow, or to experiment with new ideas.

⸻

A Quiet Pull Toward Tech

Even while immersed in medicine, I felt a quiet pull toward technology. Looking back, people around me saw it too. Friends would say, “You’d be great in tech.”

The first time I truly explored that possibility was when I built a website for a brokerage project. The freedom of creating something from scratch, of seeing an idea come to life - it left a mark on me.

And then, later on, watching someone close to me thrive after their own career switch gave me the final push I needed. I realized I didn’t have to stay stuck. I could make a change too.

⸻

Why I Really Left

I didn’t leave medicine because I gave up on it. I left because I realized there are many ways to help people, and sometimes the timing matters more than the title.

Software engineering opened up a space for me to keep solving problems, just in a different language. It brought back a sense of structure and forward momentum. And it offered something medicine could not at that moment: a fair shot to build, to test, to learn - without being defined by where I was from, my degree, or my connections.

⸻

What I Gained

Coding showed me I’m still capable of taking on hard challenges. It showed me that I can adapt, learn, and grow - even after years spent mastering something completely different.

Maybe the biggest surprise? How many of the skills I built in medicine still help me today:
• Problem-solving under pressure
• Empathy for real-world users
• Attention to detail
• Commitment to quality

The transition wasn’t easy. It was scary, even. But it taught me that reinvention is possible, no matter how far along you are in one path.

⸻

Over to You

Have you ever made a leap like this — from one world to another?
I’d love to hear your story, and maybe share more of mine, too. Feel free to connect or drop me a note anytime.

⸻

👉 Let’s connect on LinkedIn (https://www.linkedin.com/in/arttheache/) or check out my projects on GitHub (https://github.com/ArtTheAche98).