I spent an embarrassing amount of time debugging an SQS consumer that was processing messages twice and sometimes three times. The root cause turned out to be a fundamental misunderstanding of how visibility timeout, dead-letter queues, and consumer concurrency interact. Here is everything I wish I had known from the start. SQS Delivery Guarantees: At-Least-Once, Not Exactly-Once Before we dive into configuration, the most important thing to internalise: SQS guarantees at-least-once delivery . The same message may be delivered multiple times, even under normal operating conditions — not just during failures. This is not a bug; it is a deliberate design decision that enables SQS to provide high availability and scalability. Your consumer must be idempotent. Visibility Timeout: The Most Misunderstood Setting When you call ReceiveMessage , SQS makes each returned message invisible to other consumers for the visibility timeout duration. If you do not delete the message before the ti...

Graceful shutdown is one of those things every backend service needs but few teams implement correctly — until something breaks in production. I learned this the hard way when a deployment left in-flight database writes half-committed, causing data inconsistencies that took a full day to resolve. Here is the complete pattern I have settled on for Go services, including the edge cases most tutorials skip. What Happens Without Graceful Shutdown When a container orchestrator (ECS, Kubernetes) wants to stop a task, it sends SIGTERM to the process. By default, most Go servers ignore it — the process keeps accepting new connections, existing requests finish eventually, and the orchestrator gives up and sends SIGKILL , killing everything immediately. Any in-flight HTTP requests, open database transactions, or messages being processed from a queue are abandoned mid-operation. On a busy service this is guaranteed to cause problems. The real damage depends on what your service does: HTT...

The other day I was facing a problem to connect Symfony to multiple databases, there is a way to have multiple database connection in the official documentation but in that method you should define all the databases from the start, which means you can only pick a database that already has defined in your controller, you can't just connect to a database in real time. Sometimes, you may need to specify the connection parameters inside the controller itself, for example, you may want to connect to a database where the database name was specified in the URL or you want to insert data into a different databases where the database connection parameters are inside an other database... It's getting complicated, I know! Let's just say in this blog I will show how to connect dynamically to a database inside the controller. Let's start by creating a new PHP class called DynamicConnection.php and add it inside src folder, we can even create a new folder called...

I always thought that deploying an app on the server is quite easy! I mean sure you will have some errors, you may spend few hours trying to make things work on the server, you may even do different steps from setting up the server, setting up the database, make code changes, etc and as much as I always enjoyed doing that, we have to admit that this is only valid for small projects. Companies or even small startups are always making changes and adding new features, so it's not smart to waste time each time they want to deploy something new. You may have heard about CI before, maybe CI/CD, so let's see today how we can make things more professional. In this blog I will deploy a Symfony 5 project, same steps should be valid for any other framework, we just have to create our docker container file and make some changes like port mapping... In a more professional context, we should have 2 environments to deploy our app, an environment for production which have the stable ver...