DEV Community: Azam Akram

Gzip Base64 encoder / decoder

Azam Akram — Sun, 28 Jun 2026 15:44:55 +0000

Compress text with Gzip and encode the result as Base64 in a single step — or go the other way and decode then decompress a Base64 payload back to the original string. Everything runs in your browser.

https://www.solutiontoolkit.com/tools/gzip-base64-encoder-decoder

When is this useful?

API payloads: some services accept compressed, Base64-encoded bodies to reduce bandwidth. Decode them here to inspect the original JSON or XML.
Environment variables: large config blobs are often Gzip+Base64 encoded before being stored as env vars or Kubernetes secrets.
CloudWatch / logging: AWS Lambda logs shipped via Kinesis are Gzip+Base64 encoded. Paste the payload here to read the raw log lines.
Cookie compression: session cookies containing JSON are sometimes compressed to stay under browser size limits.

How it works

Compress & Encode: runs Gzip compression on your text using the pako library, then encodes the binary output as a Base64 string safe for transport in JSON, URLs, and headers.
Decompress & Decode: validates the Base64 format, decodes the bytes, then runs Gzip inflate to recover the original text.

Note: Short strings often produce a larger Base64 output than the original because Gzip's header and Base64 expansion (x1.33) outweigh the compression gain. Gzip shines on repetitive text over ~1 KB.

How to Use This Gzip Base64 Decoder and Encoder

gzip base64 decode is designed for quick browser-based work when you need to gzip compress text. Paste or select your input in the tool area above, run the conversion or formatting step, then review the result before copying it into code, documentation, tickets, test data, or an API client.

Example input:
Gzip-compressed Base64 API payload

Example output:
H4sIAAAAAAAAA3OvyizQTc7PLShKLS5OTVFwSixONTNRcAzwVChIrMzJT0wBAOnU+sEiAAAA

Common Issues to Check

A normal Base64 string will not decompress unless the decoded bytes are gzip data
Copied payloads can fail when quotes, escaping, or whitespace are included
Very large payloads can take longer because compression happens in the browser

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml

Azam Akram — Sun, 28 Jun 2026 15:36:03 +0000

solutiontoolkit.com

Your API wants JSON. Your config is YAML. Convert it here, no signup needed. https://www.solutiontoolkit.com/tools/yaml-to-json-converter #json #yaml

Azam Akram — Sat, 27 Jun 2026 23:42:12 +0000

solutiontoolkit.com

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml #converter

Azam Akram — Sat, 27 Jun 2026 23:40:03 +0000

solutiontoolkit.com

Tired of pasting JSON into random sites? Here's a free in-browser validator - nothing leaves your machine. https://www.solutiontoolkit.com/tools/validate-and-prettify-json #json #pretty #validate

Azam Akram — Sat, 27 Jun 2026 23:37:58 +0000

solutiontoolkit.com

Check live scores, full group stage schedule, and knockout fixtures all in one place: 👉 https://www.solutiontoolkit.com/world-cup-2026/schedule #WorldCup2026 #FIFA2026 #NextJS #SolutionToolkit #WebDev #Football

Azam Akram — Thu, 25 Jun 2026 23:18:46 +0000

solutiontoolkit.com

Debugging GZip Base64 compressed payloads from AWS API Gateway / Lambda

Azam Akram — Mon, 22 Jun 2026 17:40:12 +0000

You call an API. The response comes back and one of the fields looks like this:

H4sIAAAAAAAAE6tWKkktLlGyUlIqS04sLknMSwUAAAD//wMAAAD//w==

If you have ever looked at something like that wondering what is hiding inside, you are looking at a GZip-compressed payload encoded in Base64.

This pattern appears more often than you might expect — in AWS, Azure, Kafka, webhook systems, and internal microservices. Understanding why it exists and how to quickly decode it will save you time every time you hit it.

Just need to decode one now? Paste the string into the GZip Base64 Encoder / Decoder and get the result instantly — no terminal required.

The Problem: Binary Data in Text Channels

GZip compression produces binary output — raw bytes that can include any value from 0 to 255. Most text-based protocols (HTTP headers, JSON fields, environment variables, message queues) are designed for printable characters. If you try to embed raw binary bytes into a JSON string, you will get parsing errors or silent data corruption.

Base64 solves this by converting binary data into a safe alphabet of 64 printable ASCII characters. The trade-off is a roughly 33% increase in size — but after GZip compression, the total payload is still significantly smaller than the original.

Why APIs Combine GZip and Base64

The two techniques solve different problems and work well together:

GZip reduces size. For repetitive, structured data like JSON or XML, GZip typically achieves 60–80% compression. A 100 KB JSON payload can compress to 15–20 KB.

Base64 makes binary data safe to transport. It guarantees the compressed bytes can be embedded in a JSON field, stored in a database column, passed through an environment variable, or included in a URL query string without corruption.

Together they allow a system to transmit large, structured payloads efficiently through channels that only support text.

Real-World Examples

AWS Lambda and API Gateway — response bodies larger than a certain threshold can be returned as Base64-encoded compressed content, with a flag telling the client to decompress
Kafka messages — event payloads are often GZip + Base64 encoded before publishing so they fit within message size limits and serialize cleanly
Webhook events — third-party services sometimes send compressed event data to reduce egress costs
Distributed tracing / logging — trace context or structured log data embedded in HTTP headers

How to Debug a Compressed Payload

When you encounter one of these strings during development or debugging, the workflow is straightforward:

Copy the encoded string from the API response, log line, or message payload
Decode the Base64 layer to recover the GZip binary
Decompress the GZip to recover the original data

In a terminal you can do this with:

echo "H4sIAAAAAAAAE6tWKkktLlGyUlIqS04sLknMSwUAAAD//wMAAAD//w==" \
  | base64 --decode \
  | gunzip

That works fine in a Linux or macOS shell. On Windows, or when you just want a quick result without opening a terminal, an online tool is faster.

Decode It Instantly

The GZip Base64 Encoder / Decoder tool on this site handles both directions — paste your encoded string to decode it, or paste plain text and JSON to compress and encode it. No installation, no terminal, works in the browser with no data leaving your machine.

It is useful when you need to inspect a payload quickly during an incident, verify what a service is actually sending before writing decoding logic in your application, or compress test data to embed in a config or environment variable.

The next time you hit an unreadable string in an API response, you will know exactly what it is and how to open it up.

Generate MD5, SHA-1, SHA-256, and SHA-512 Hashes Instantly in Your Browser

Azam Akram — Thu, 18 Jun 2026 17:32:40 +0000

A free, client-side tool for hashing text — no installation, no account, no server.

What Is a Hash and When Do You Need One?

A hash function takes any input — a word, a sentence, a JSON blob — and produces a fixed-length string of characters. The same input always produces the same output. Change even a single character and the output changes completely.

Developers reach for hashing in a surprisingly wide range of situations:

Verifying data integrity — confirm a file or string has not been tampered with
Checksums — compare two pieces of data without storing or transmitting the originals
Password storage — store a hash instead of a plaintext password (with a proper algorithm)
Caching and deduplication — use a hash as a unique key for a piece of content
Debugging — quickly fingerprint a string to check if two values are identical across environments
The Text Hash Generator lets you generate hashes across all four commonly used algorithms in one step, directly in your browser.

The Four Algorithms

MD5–128-bit MD5 is fast and widely recognised. It is no longer considered cryptographically secure for security-sensitive use cases, but remains practical for checksums, non-security fingerprinting, and working with legacy systems that expect MD5 output.

SHA-1–160-bit SHA-1 is similarly deprecated for security use but still appears in older protocols, version control systems, and certificate chains. Useful when you need to match or verify a SHA-1 value produced by another system.

SHA-256–256-bit SHA-256 is the workhorse of modern cryptography. It is part of the SHA-2 family and is widely used in TLS certificates, code signing, blockchain, and general-purpose integrity verification. When in doubt, use SHA-256.

SHA-512–512-bit SHA-512 produces a longer digest and offers a higher security margin. It is preferred in high-security contexts and, on 64-bit processors, can actually be faster than SHA-256 due to how modern CPUs handle 64-bit operations.

What the Tool Does

Open the Text Hash Generator, type or paste any text, and click Generate Hashes (or press Ctrl+Enter). All four hashes are computed and displayed simultaneously.

Uppercase toggle Switch between lowercase and uppercase hex output with a single checkbox. Some systems expect uppercase hash strings — this saves you a manual conversion step.

Copy individual or all Each hash has its own Copy button. There is also a Copy all hashes option that puts all four results on the clipboard in a labelled format, ready to paste into documentation or a ticket.

Character count The input field shows a live character count as you type, useful when you need to know the exact length of the string you are hashing.

How It Works

SHA-1, SHA-256, and SHA-512 are computed using the browser’s built-in Web Crypto API via crypto.subtle.digest. MD5 is handled by the js-md5 library, since MD5 is not included in the Web Crypto API (intentionally — browsers do not endorse it for cryptographic use). All four run client-side. Open DevTools, go to the Network tab, type some text, and generate — you will see zero outbound requests.

Try It
Open the Text Hash Generator — paste any text and get all four hashes in one click.

The Text Hash Generator is one of several developer tools at SolutionToolkit. All tools run client-side with no server-side processing.

A Client-Side JWT Debugger That Runs Entirely in Your Browser

Azam Akram — Thu, 18 Jun 2026 13:08:27 +0000

Why Another JWT Tool?
Most JWT debugging workflows involve copying a token into an online tool, inspecting the payload, and moving on. That works fine for simple use cases, but falls short when you need to do more — sign a token with a specific algorithm, verify a signature against a public key, or quickly check whether a token has expired.

The JWT Debugger is a free, browser-based tool that covers the full JWT workflow: decode, inspect, sign, and verify — all in one place, with no installation and no account required.
What It Does

Decode and inspect Paste any JWT and the tool splits it into header, payload, and signature — colour-coded so each part is visually distinct. Timestamp claims (iat, exp, nbf) are automatically converted to human-readable dates with a relative time display ("expires in 2h", "3 days ago").

Status at a glance A badge shows whether the token is Active, Expired, or has No Expiry set. If a token is expired, you see exactly how long ago — no manual Unix timestamp conversion needed.

Sign tokens Build a header and payload from scratch and sign them. All twelve standard algorithms are supported:

FamilyAlgorithmsHMACHS256, HS384, HS512RSA PKCS#1RS256, RS384, RS512RSA-PSSPS256, PS384, PS512ECDSAES256, ES384, ES512

For HMAC algorithms, enter your shared secret. For asymmetric algorithms, paste your PKCS#8 private key. The tool signs the token locally using crypto.subtle.sign and gives you the complete JWT.

Verify signatures Paste a JWT and your key, click Verify, and the tool confirms whether the signature is valid. For RSA and ECDSA, paste the public key in SPKI PEM format. Verification runs entirely in crypto.subtle.verify.

Edit and re-encode Modify the header or payload JSON and the encoded token updates in real time. Useful for quickly testing how a claim change affects the token structure, or for building a test token before signing it.

How It Works Under the Hood
The tool is built on the Web Crypto API — a browser-native cryptography interface available in all modern browsers. There are no third-party cryptography libraries. Every signing and verification operation calls crypto.subtle directly.

Base64url encoding and decoding are handled with TextEncoder and atob/btoa. PEM keys are stripped of their headers and decoded from base64 before being passed to crypto.subtle.importKey. The signing input follows the JWT spec — base64url(header) + "." + base64url(payload) — and the resulting signature bytes are base64url-encoded and appended as the third segment.

If you want to verify the behaviour yourself: open DevTools, go to the Network tab, and paste a token. You will see zero outbound requests.

Try It
Open the JWT Debugger and paste any JWT into the top field. The decoded header and payload appear immediately. No account, no signup.

If you want to understand the theory behind what you are looking at — how the header, payload, and signature fit together, what RS256 means, and how the private/public key split works — the companion article JWT Shared Secret: How JWTs are Signed and Shared Across Services covers the fundamentals.

The JWT Debugger is one of several developer tools at SolutionToolkit. All tools run client-side with no server-side processing.

I Built a Collection of 50+ Free Developer Tools That Run Entirely in the Browser

Azam Akram — Tue, 09 Jun 2026 00:01:16 +0000

I Built a Collection of 50+ Free Developer Tools That Run Entirely in the Browser

As developers, we constantly run into small tasks that interrupt our workflow:

Formatting JSON
Decoding JWTs
Converting timestamps
Comparing configuration files
Generating UUIDs
Building cron expressions

Most of these tasks don't require a full application or a paid SaaS product. They just need a simple utility that works immediately.

That's why I started building Solution Toolkit — a collection of browser-based developer tools focused on everyday development tasks.

My Goals

When building the toolkit, I wanted it to be:

Free to use
No sign-up required
Privacy-first
Fast and lightweight
Available directly in the browser

Most tools run entirely client-side, so data never leaves your device.

What's Included?

Some of the categories currently available:

JSON & API Tools

JSON Formatter
JSON Validator
JSON Escape / Unescape
JSON Converters
JWT Debugger

Encoding & Decoding

Base64 Encoder / Decoder
URL Encoder / Decoder
HTML Encoder / Decoder
ASCII Converter
GZip Base64 Decoder

Formatting & Validation

SQL Formatter
YAML Formatter
CSS Formatter
JavaScript Formatter
HTML Formatter
Markdown Formatter

Developer Utilities

UUID Generator
Cron Expression Builder
Epoch Timestamp Converter
QR Code Generator
Hash Generators

Image Tools

Image Compression
Image Resizing
PNG/JPG/WebP Conversion
SVG Utilities

What I Learned Building It

A few things surprised me:

Developers care a lot about privacy for utility tools.
Browser APIs are powerful enough to handle many tasks entirely client-side.
Small utilities often provide more daily value than large applications.

Looking for Feedback

I'm actively adding new tools and improving existing ones.

What browser-based developer tool do you wish existed?

Or what's a utility you find yourself searching for repeatedly?

I'd love to hear suggestions.

🔗 Project: https://www.solutiontoolkit.com

AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)

Azam Akram — Mon, 08 Jun 2026 23:38:40 +0000

In any well-architected cloud setup, managing traffic efficiently and scaling resources on demand are key to keeping your applications fast, reliable, and cost-efficient.

AWS makes this easy with two core services: the Elastic Load Balancer (ELB) for routing traffic, and Auto Scaling Groups (ASG) for automatically adjusting compute capacity as traffic changes.

The AWS Elastic Load Balancer automatically distributes incoming requests across multiple targets, such as, EC2 instances, containers, or IPs, across different Availability Zones (AZs). AWS offers several types of load balancers, including Application, Network, and Gateway Load Balancers, each suited for different scenarios.

In this guide, we’ll set up an Application Load Balancer (ALB) connected to an Auto Scaling Group (ASG) using the AWS CLI.

Our setup will dynamically launch and manage EC2 instances, organized into a Target Group, ensuring smooth load distribution and high availability.

What We'll Do

Create a security group to allow necessary inbound traffic.
Define a launch template with EC2 instance configuration and a user-data script to deploy a simple web server.
Set up an Auto Scaling Group (ASG) to handle scaling based on demand.
Create a Target Group to manage and distribute traffic.
Configure an Application Load Balancer (ALB) and listener, linking it to the Target Group for seamless load balancing.

Prerequisites

An AWS account. If you don’t have one, follow this quick guide to create a free-tier AWS account.
AWS access keys configured in your local CLI environment. These are needed for deploying resources. Check out Section 9 of our AWS starter guide for details.

Why Combine ALB with ASG?

Pairing an Application Load Balancer (ALB) with an Auto Scaling Group (ASG) gives you a scalable, cost-effective, and fault-tolerant setup. Here’s why it’s a great combo:

Automatic Scaling – ASG adjusts the number of EC2 instances in real time as traffic changes.
Cost Optimization – You only pay for what you use, saving costs during low-traffic hours.
High Availability – ALB spreads requests across healthy instances in multiple AZs, avoiding single points of failure.
Better Fault Tolerance – If one instance fails, ALB automatically routes traffic to healthy ones, ensuring smooth performance.

Let’s dive in and start building!

Step 1: Create a Security Group

Before launching EC2 instances or attaching them to a Load Balancer, we need to define a security group, which is a virtual firewall that controls inbound and outbound traffic. In this step, we’ll create a security group that allows SSH (for remote access) and HTTP (for web traffic) connections.

Run the following command to create a new security group:

aws ec2 create-security-group \
  --group-name my-test-security-group \
  --description "Security Group for My ALB" \
  --region <your-region-id>

This command creates a security group in your specified AWS region. Next, we’ll add inbound rules that define what types of traffic are allowed to reach our EC2 instances.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>

This rule enables SSH access on port 22, allowing you to connect to the instance from your terminal or SSH client.
We use tcp as the protocol since SSH operates over the TCP layer.

Note: Allowing SSH from all IP addresses (0.0.0.0/0) is convenient for testing, but not secure for production. In real deployments, you should restrict this to your own IP or a trusted network range, for example: --cidr 203.0.113.25/32

Now we create another inbound rule to allow HTTP traffic on port 80 over TCP.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-console.webp"
alt="ec2-security-group-console"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Let's verify the security group in the AWS Management Console:

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-gui.webp"
alt="ec2-security-group-gui"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 2: Create a Launch Template

An AWS Launch Template is a reusable blueprint that defines the configuration settings for your EC2 instances, such as the AMI, instance type, key pair, security groups, and optional user-data scripts.

Using a launch template helps standardize instance launches and simplifies scaling operations within an Auto Scaling Group (ASG).

In this step, we’ll manually create a launch template using the AWS Management Console.

Open the EC2 Dashboard in the AWS Management Console.
In the left sidebar, choose Launch Templates, then click Create launch template.
Enter a name, such as MyLaunchTemplate.
Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI (eligible for the free tier).
Choose an Instance type, e.g., t2.micro.
Skip the Key pair step for now (this is fine for testing, but in production, you should always create one for SSH access).
Under Network settings, select the previously created security group (my-test-security-group).
Expand Advanced details and paste the following user data script to automatically install and configure a simple web server. Finally, click Create launch template.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

# Get the EC2 instance's availability zone
EC2AZ=$(TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/placement/availability-zone)

# Create a simple HTML file with the availability zone info
echo '<center><h1>Hello from Web Server in Availability Zone: AZID </h1></center>' > /var/www/html/index.txt
sed "s/AZID/$EC2AZ/" /var/www/html/index.txt > /var/www/html/index.html

This user-data script runs automatically when the instance starts. It:

Installs and enables the Apache (httpd) web server.
Fetches the Availability Zone from the instance’s metadata.
Displays a custom message in the browser showing the zone where the instance is running — useful when testing load balancing across multiple zones.

Note:

Every EC2 instance has access to instance metadata, which contains information like instance ID, region, IP addresses, and Availability Zone.

AWS exposes this data through a special internal endpoint — 169.254.169.254 — accessible only from within the instance.

Learn more about instance metadata in the official AWS documentation.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/launch-template.webp"
alt="launch-template"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 3: Create an Auto Scaling Group (ASG)

Now we will create an Auto Scaling group named "my-auto-scaling-group" using a launch template we previously created "MyLaunchTemplate." It sets the desired capacity to 2 instances, with a minimum of 1 and a maximum of 5 instances, distributed across two availability zones. The instances are launched in two different subnets within a Virtual Private Cloud (VPC) to ensure scalability and high availability.

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-auto-scaling-group \
  --launch-template "LaunchTemplateName=MyLaunchTemplate" \
  --min-size 1 --max-size 5 --desired-capacity 2 \
  --availability-zones "<availability-zone-1>" "<availability-zone-2>" \
  --vpc-zone-identifier "<subnet-id-1>,<subnet-id-2>"

Note: Replace <subnet-id-x> and <availablity-zone-x> according to your setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/security-group.webp"
alt="security-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 4: Create Target Group and Load Balancer

Create a Target Group

A Target Group defines the set of resources (such as EC2 instances) that an Application Load Balancer (ALB) routes incoming requests to. It continuously performs health checks to ensure traffic is sent only to healthy instances, improving reliability and availability.

In this step, we’ll create an HTTP-based target group named my-target-group that listens on port 80 within your VPC. This target group will later be linked to your Auto Scaling Group (ASG) so that any new instances launched by the ASG are automatically registered as targets.

aws elbv2 create-target-group \
--name my-target-group \
--protocol HTTP \
--port 80 \
--vpc-id <vpc-id>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: Target group is created but no EC2 instances are registered yet. Instances will be registered automatically once the Auto Scaling Group is attached in a later step.

Create an Application Load Balancer (ALB)

An Application Load Balancer (ALB) intelligently distributes incoming HTTP and HTTPS traffic across multiple targets, such as EC2 instances, in one or more Availability Zones (AZs).

The following command creates an ALB named my-alb, specifying the subnets and security groups that determine where and how the load balancer operates:

aws elbv2 create-load-balancer \
--name my-alb \
--subnets <subnet-id-1> <subnet-id-2> \
--security-groups <security-group-id> \

This command:

Creates an Application Load Balancer called my-alb.
Associates it with two subnets (usually in different Availability Zones) for high availability.
Applies the specified security group, which defines what inbound and outbound traffic is allowed for the load balancer.

Note: Replace <subnet-id-1>, <subnet-id-2>, and <security-group-id> with actual values from your AWS setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-load-balancer.webp"
alt="create-load-balancer"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: You need to note down LoadBalancerArn, which we will use in coming sections.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/load-balancer-setting.webp"
alt="load-balancer-setting"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Create a Listener and Link it to the Target Group

A Listener is a key component of an Application Load Balancer (ALB). It checks for incoming connection requests on a specific port and protocol, then forwards the traffic to a designated Target Group based on defined rules.
In this step, we’ll create an HTTP listener on port 80 for our ALB, which will route all incoming web requests to the previously created target group.

aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=<target-group-arn>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-listener.webp"
alt="create-listener"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Attach the Target Group to the Auto Scaling Group

The Target Group must be linked to your Auto Scaling Group (ASG) so that any instances launched by the ASG are automatically registered with the Application Load Balancer (ALB).

This ensures that traffic is distributed only to healthy, actively running instances managed by the ASG.

Use the following command to attach the target group to your Auto Scaling group named ASG1:

aws autoscaling attach-load-balancer-target-groups \
  --auto-scaling-group-name ASG1 \
  --target-group-arns <target-group-arn>

This command:

Connects the specified Target Group to your ASG.
Ensures that new instances launched by the ASG are automatically added to the target group for load balancing.
Enables health checks so unhealthy instances are replaced automatically.

After this step, the Auto Scaling Group will launch two EC2 instances (based on the desired capacity you configured earlier).

Once these instances pass their health checks, they’ll be marked as healthy, and the ALB will begin routing traffic to them automatically.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-auto-scaling.webp"
alt="create-auto-scaling"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

We can also check the Target Group to see that both instances are healthy.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 5: Testing the Load Balancer

To verify that the Application Load Balancer (ALB) is correctly distributing traffic, open the ALB Dashboard in the AWS Management Console and note down the DNS name of your ALB.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/test-elb.webp"
alt="test-elb"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Enter this ALB DNS name in your web browser.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-1.webp"
alt="browser-elb-1"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Now, refresh the browser several times.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-2.webp"
alt="browser-elb-2"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

As you refresh, you’ll notice that the web page alternates between different Availability Zones (AZs). This confirms that the Application Load Balancer is intelligently distributing incoming traffic across multiple EC2 instances (targets) in different zones.

Each request may reach a different instance within the Target Group, depending on factors like health status, capacity, and routing algorithm.

In summary, this test proves that your ALB and Auto Scaling Group (ASG) are working together as intended, automatically balancing the load between multiple healthy EC2 instances.

Step 6: Deleting the Setup

Once you’ve verified that your Application Load Balancer (ALB) and Auto Scaling Group (ASG) are working correctly, it’s good practice to clean up the resources to avoid ongoing AWS charges.

Run the following commands to delete the setup:

aws elbv2 delete-load-balancer --load-balancer-arn <alb-arn>
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name ASG1 --force-delete

These commands:

Remove the ALB and its associated listeners and target group.
Delete the Auto Scaling Group along with any EC2 instances it launched (using the --force-delete flag ensures immediate deletion).

Note: You may also want to delete other related resources such as the launch template, target group, and security group if they are no longer needed.

Conclusion

You’ve successfully set up an AWS Application Load Balancer (ALB) integrated with an Auto Scaling Group (ASG) and Target Group — all using the AWS CLI.

This architecture automatically adjusts capacity based on demand while distributing traffic evenly across multiple instances, ensuring:

High availability across Availability Zones,
Fault tolerance through automatic health checks and scaling, and
Cost efficiency by running only the resources you need.

With this foundation, you can now expand the setup, for example, adding HTTPS with an SSL certificate, customizing health checks, or deploying containerized workloads behind the load balancer.

Thanks for reading!

If you found this article useful, you may also enjoy the other technical articles, tutorials, and free developer tools I build at:

Solution Toolkit

You'll find browser-based tools for JSON, JWTs, YAML, timestamps, UUIDs, image processing, encoding/decoding, and many other everyday development tasks.

Building Kafka Producer-Consumer Using Go and Docker

Azam Akram — Mon, 08 Jun 2026 23:34:22 +0000

In this blog, we'll walk through the process of building Kafka Producer and Consumer microservices using Go, integrated with Docker.

We will,

Build a Go Kafka producer with an HTTP endpoint.
Build a Go Kafka consumer with retry and dead-letter support.
Set up Kafka using Docker (KRaft mode — no Zookeeper required).
Run the application end-to-end.

Introduction

Microservices architecture is a popular approach for building scalable and maintainable applications. By breaking down applications into smaller, independent services, developers can enhance flexibility and streamline deployment cycles. We will implement Kafka producer and consumer applications in Go and demonstrate how to run Kafka in a Docker container with Docker Compose to create a seamless microservices environment.

Go

Go is an open-source, statically typed, compiled language designed at Google for simplicity, reliability, and efficiency. It ships with a rich standard library, first-class concurrency primitives (goroutines and channels), and produces single, statically-linked binaries — making it an excellent fit for microservices and containerised workloads.

Apache Kafka

Kafka is a distributed streaming platform used to build real-time data pipelines and streaming applications. It allows producers to send messages to topics, which are then consumed by various consumers, making it ideal for event-driven architectures.

Docker

Docker is a platform that allows developers to automate the deployment of applications inside lightweight, portable containers. With Docker Compose, you can manage services like Kafka in isolated containers, making it easy to build and maintain microservices architectures.

Prerequisites

Go 1.22 or later. If you haven't installed Go yet, this guide walks you through the setup.
Docker
Docker Compose
Basic knowledge of Go and Kafka

Download Code from Github

Download full code from this github repository.

Project Overview

We will create two Go applications:

Kafka Producer: Exposes a GET /send HTTP endpoint that publishes a message to a Kafka topic.
Kafka Consumer: Connects to the topic, processes each message, and retries on failure with dead-letter support.

kafka-docker-go/
├── kafka-producer/
│   ├── go.mod
│   ├── main.go
│   ├── producer.go
│   ├── handler.go
│   └── model.go
├── kafka-consumer/
│   ├── go.mod
│   ├── main.go
│   ├── consumer.go
│   └── model.go
└── docker-compose.yml

Building and Running the Application

Docker Compose for Kafka Setup

Before we start building the Go producer and consumer, we first need a running Kafka instance locally. Instead of manually installing Kafka and managing all its dependencies, we'll use Docker Compose to spin up a ready-to-use environment in a single command.

We'll be using Apache Kafka running in KRaft mode (Kafka without ZooKeeper). Traditionally, Kafka relied on Apache ZooKeeper for cluster coordination, but modern Kafka versions (3.3+) have introduced KRaft (Kafka Raft metadata mode), which simplifies the architecture by removing ZooKeeper entirely.

docker-compose.yml:

This configuration provisions a single Kafka broker that also acts as a controller (KRaft mode):

services:
  kafka:
    image: apache/kafka:latest
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: 'broker,controller'
      KAFKA_CONTROLLER_QUORUM_VOTERS: '1@localhost:9093'
      KAFKA_LISTENERS: 'PLAINTEXT://:9092,CONTROLLER://:9093'
      KAFKA_ADVERTISED_LISTENERS: 'PLAINTEXT://localhost:9092'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: 'CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT'
      KAFKA_CONTROLLER_LISTENER_NAMES: 'CONTROLLER'
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

KAFKA_PROCESS_ROLES: 'broker,controller'
Instructs this single container to act simultaneously as both the metadata controller and the message broker, completely eliminating the need for ZooKeeper.
KAFKA_ADVERTISED_LISTENERS
Defines the network address and port (localhost:9092) that external clients, such as your Go producers and consumers, will use to connect to the cluster.
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
Sets the replication factor for the internal offsets topic to 1. This is ideal for single-node local development, ensuring the cluster stays healthy without requiring peer nodes.

To launch your local Kafka environment in detached mode, run:

$ docker-compose up -d
[+] up 2/2
 ✔ Network golang-kafka-docker_default  Created                          0.0s
 ✔ Container kafka                      Started

Verify the container is running:

$ docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED         STATUS         PORTS                    NAMES
ae58e1252135   apache/kafka:latest  "/__cacert_entrypoin…"   3 minutes ago   Up 3 minutes   0.0.0.0:9092->9092/tcp   kafka

Now that Kafka is running, let's quickly verify it using the built-in console tools.

In a terminal, start a Kafka console consumer that reads all messages from the beginning of the topic:

I wrote following command in git Bash. Git Bash on Windows automatically converts paths starting with / to Windows paths, turning /opt/kafka/bin/... into C:/Program Files/Git/opt/kafka/bin/....
SO I wrote path starting with double slashes, //opt/kafka/bin/kafka-console-consumer.sh

docker exec -it kafka //opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic demo-kafka-topic \
  --from-beginning

In a second terminal, start a producer to send a test message:

docker exec -it kafka //opt/kafka/bin/kafka-console-producer.sh \
  --bootstrap-server localhost:9092 \
  --topic demo-kafka-topic

Type a message and press Enter:

Hello from kafka Producer

The consumer terminal will immediately display:

Hello from kafka Producer

src="/static/images/golang-kafka-producer-consumer-with-docker/kafka-producer-consumer-manual-test.webp"
alt="kafka-producer-consumer-manual-test"
className="mx-auto my-6 h-5/6 w-5/6 rounded-lg shadow-lg"
/>

Kafka Consumer Service (Go)

Now that our Kafka broker is running, let's build the consumer service that listens to messages from the topic and processes them in real time.

We'll use kafka-go — a pure Go Kafka client that is a light-weight dependency, and gives fine-grained control over offset commits.

`go.mod`

module github.com/azam-akram/kafka-docker-go/kafka-consumer

go 1.22

require github.com/segmentio/kafka-go v0.4.51

Run go mod tidy after creating this file to download the dependency.

Message Model (`model.go`)

The Message struct is the shared data contract between producer and consumer. It is marshalled to JSON by the producer and unmarshalled back by the consumer.

package main

type Message struct {
    UUID    string `json:"uuid"`
    From    string `json:"from"`
    To      string `json:"to"`
    Message string `json:"message"`
}

Kafka Consumer (`consumer.go`)

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "time"

    "github.com/segmentio/kafka-go"
)

const (
    maxRetries = 3
    retryDelay = time.Second
)

type KafkaConsumer struct {
    reader    *kafka.Reader
    dlqWriter *kafka.Writer
}

func NewKafkaConsumer(broker, topic, groupID string) *KafkaConsumer {
    dlqTopic := topic + "-dlt"
    return &KafkaConsumer{
        reader: kafka.NewReader(kafka.ReaderConfig{
            Brokers:     []string{broker},
            Topic:       topic,
            GroupID:     groupID,
            MinBytes:    10e3,
            MaxBytes:    10e6,
            StartOffset: kafka.FirstOffset,
        }),
        dlqWriter: &kafka.Writer{
            Addr:                   kafka.TCP(broker),
            Topic:                  dlqTopic,
            Balancer:               &kafka.LeastBytes{},
            AllowAutoTopicCreation: true,
        },
    }
}

// Run fetches messages in a loop until ctx is cancelled.
func (c *KafkaConsumer) Run(ctx context.Context) {
    for {
        m, err := c.reader.FetchMessage(ctx)
        if err != nil {
            if ctx.Err() != nil {
                return // clean shutdown on SIGTERM / SIGINT
            }
            log.Printf("ERROR fetch: %v", err)
            continue
        }

        if err := c.processWithRetry(m); err != nil {
            log.Printf("ERROR retries exhausted, routing to DLQ — uuid=%s", string(m.Key))
            c.sendToDLQ(ctx, m)
        }

        if err := c.reader.CommitMessages(ctx, m); err != nil {
            log.Printf("ERROR commit: %v", err)
        }
    }
}

func (c *KafkaConsumer) processWithRetry(m kafka.Message) error {
    var lastErr error
    for attempt := 1; attempt <= maxRetries; attempt++ {
        if err := process(m); err != nil {
            lastErr = err
            log.Printf("WARN attempt %d/%d failed: %v", attempt, maxRetries, err)
            if attempt < maxRetries {
                time.Sleep(retryDelay)
            }
            continue
        }
        return nil
    }
    return lastErr
}

func process(m kafka.Message) error {
    var msg Message
    if err := json.Unmarshal(m.Value, &msg); err != nil {
        return fmt.Errorf("unmarshal: %w", err)
    }

    log.Println("=================================")
    log.Println("Received message:")
    log.Printf("  UUID:    %s", msg.UUID)
    log.Printf("  From:    %s", msg.From)
    log.Printf("  To:      %s", msg.To)
    log.Printf("  Message: %s", msg.Message)
    log.Println("=================================")
    return nil
}

func (c *KafkaConsumer) sendToDLQ(ctx context.Context, m kafka.Message) {
    if err := c.dlqWriter.WriteMessages(ctx, kafka.Message{
        Key:   m.Key,
        Value: m.Value,
    }); err != nil {
        log.Printf("ERROR DLQ write: %v", err)
    }
}

func (c *KafkaConsumer) Close() {
    c.reader.Close()
    c.dlqWriter.Close()
}

Key design decisions explained:

kafka.NewReader with GroupID: registering a GroupID enables consumer-group semantics — Kafka assigns partitions to group members and tracks committed offsets per group. Multiple consumer instances sharing the same GroupID can scale horizontally across partitions.
FetchMessage vs ReadMessage: kafka-go provides two fetch APIs. ReadMessage automatically commits the offset after each fetch, which risks marking a message as processed even if your handler panics. FetchMessage leaves the offset uncommitted; we call CommitMessages only after the message has been fully processed (or routed to the DLQ). This gives us at-least-once delivery semantics.
StartOffset: kafka.FirstOffset: equivalent to auto-offset-reset: earliest in a Spring Boot config. On first start (no committed offset for the group), the consumer reads from the beginning of the topic.
processWithRetry: wraps process in a simple retry loop — up to maxRetries attempts with a retryDelay between each. If a transient error causes process to fail, the message is retried in place before being sent to the DLQ.
Dead-letter topic (-dlt suffix): if all retry attempts are exhausted, the raw message bytes are forwarded to demo-kafka-topic-dlt. Failed messages are captured for inspection or manual reprocessing rather than silently dropped — the same pattern as @DltHandler in Spring Kafka.

Application Entry Point (`main.go`)

package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
)

func main() {
    broker := "localhost:9092"
    topic := "demo-kafka-topic"
    groupID := "demo-kafka-consumer"
    port := "5555"

    consumer := NewKafkaConsumer(broker, topic, groupID)
    defer consumer.Close()

    // Simple health endpoint
    go func() {
        mux := http.NewServeMux()
        mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
            w.Header().Set("Content-Type", "application/json")
            w.Write([]byte(`{"status":"up"}`))
        })
        log.Printf("Health endpoint on :%s", port)
        http.ListenAndServe(":"+port, mux)
    }()

    ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer cancel()

    log.Printf("Consumer started topic=%s group=%s", topic, groupID)
    consumer.Run(ctx)
    log.Println("Consumer stopped")
}

signal.NotifyContext: creates a context that is cancelled when the process receives SIGINT (Ctrl+C) or SIGTERM (e.g. from docker stop). When the context is cancelled, FetchMessage returns immediately, allowing the Run loop to exit cleanly.
Health goroutine: a minimal GET /health endpoint runs on port 5555 in a background goroutine, so the consumer can be probed by Docker health checks or an orchestrator without interfering with the main consume loop.

Kafka Producer Service (Go)

The producer service exposes a simple REST endpoint. When called, it builds a Message and publishes it to the Kafka topic.

`go.mod`

module github.com/azam-akram/kafka-docker-go/kafka-producer

go 1.22

require github.com/segmentio/kafka-go v0.4.47

Message Model (`model.go`)

The producer's Message model mirrors the consumer's exactly, ensuring the JSON wire format is compatible on both sides.

package main

type Message struct {
    UUID    string `json:"uuid"`
    From    string `json:"from"`
    To      string `json:"to"`
    Message string `json:"message"`
}

In a larger system you would extract this into a shared Go module to avoid duplication.
For this self-contained example, both services define their own copy.

Kafka Producer (`producer.go`)

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/segmentio/kafka-go"
)

type KafkaProducer struct {
    writer *kafka.Writer
}

func NewKafkaProducer(broker, topic string) *KafkaProducer {
    return &KafkaProducer{
        writer: &kafka.Writer{
            Addr:                   kafka.TCP(broker),
            Topic:                  topic,
            Balancer:               &kafka.LeastBytes{},
            RequiredAcks:           kafka.RequireOne,
            AllowAutoTopicCreation: true,
        },
    }
}

func (p *KafkaProducer) Send(ctx context.Context, msg Message) error {
    value, err := json.Marshal(msg)
    if err != nil {
        return fmt.Errorf("marshal: %w", err)
    }

    if err := p.writer.WriteMessages(ctx, kafka.Message{
        Key:   []byte(msg.UUID),
        Value: value,
    }); err != nil {
        return fmt.Errorf("write: %w", err)
    }

    log.Printf("Sent  uuid=%s topic=%s", msg.UUID, p.writer.Topic)
    return nil
}

func (p *KafkaProducer) Close() error {
    return p.writer.Close()
}

Key design decisions:

RequiredAcks: kafka.RequireOne: the broker acknowledges the write once the leader partition has persisted the message. This balances throughput and durability for a single-node development setup. In production, use kafka.RequireAll to wait for all in-sync replicas.
AllowAutoTopicCreation: true: if demo-kafka-topic does not exist yet, the broker creates it automatically on first write — no need to pre-create topics manually.
Message key set to UUID: using the UUID as the partition key ensures messages with the same UUID always land on the same partition. For random distribution across partitions, omit the key.
fmt.Errorf("...: %w", err): wraps errors with context using the %w verb so callers can use errors.Is / errors.As for structured error handling.

HTTP Handler (`handler.go`)

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "time"

    "github.com/google/uuid"
)

type SendHandler struct {
    producer *KafkaProducer
}

func (h *SendHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    msg := Message{
        UUID:    uuid.New().String(),
        From:    "Alice",
        To:      "Bob",
        Message: "Hello from Go producer",
    }

    ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
    defer cancel()

    if err := h.producer.Send(ctx, msg); err != nil {
        log.Printf("ERROR send: %v", err)
        http.Error(w, "failed to send message", http.StatusInternalServerError)
        return
    }

    fmt.Fprintln(w, "Message sent!")
}

ServeHTTP: implementing the http.Handler interface directly (rather than a plain func) lets us inject the *KafkaProducer dependency cleanly and register the handler with mux.Handle("/send", &SendHandler{...}).
context.WithTimeout: the send is bound to a 5-second deadline. If the Kafka broker is unavailable, WriteMessages returns promptly with a deadline-exceeded error rather than hanging the HTTP request indefinitely.
newUUID: generates a RFC 4122 v4 UUID via github.com/google/uuid.

Application Entry Point (`main.go`)

package main

import (
    "log"
    "net/http"
)

func main() {
    broker := "localhost:9092"
    topic := "demo-kafka-topic"
    port := "4444"

    producer := NewKafkaProducer(broker, topic)
    defer producer.Close()

    mux := http.NewServeMux()
    mux.Handle("/send", &SendHandler{producer: producer})
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.Write([]byte(`{"status":"up"}`))
    })

    log.Printf("Producer listening on :%s", port)
    log.Fatal(http.ListenAndServe(":"+port, mux))
}

The producer uses Go's built-in net/http server, no third-party web framework needed. A GET /health endpoint is registered alongside /send so that the service can be health-checked by Docker or an orchestrator.

Running the Application End-to-End

Step 1 — Start Kafka

docker-compose up -d

Step 2 — Start the Consumer

From the kafka-consumer directory:

go mod tidy
go run .

The consumer starts on port 5555 and begins listening to demo-kafka-topic.

2026/05/29 10:00:00 Health endpoint on :5555
2026/05/29 10:00:00 Consumer started topic=demo-kafka-topic group=demo-kafka-consumer

Step 3 — Start the Producer

From the kafka-producer directory:

go mod tidy
go run .

The producer starts on port 4444.

2026/05/29 10:00:05 Producer listening on :4444

Step 4 — Send a Message

Trigger the producer's REST endpoint:

curl http://localhost:4444/send

You should see the response:

Message sent!

Step 5 — Observe the Consumer Logs

In the consumer terminal you will see:

=================================
Received message:
  UUID:    3f2504e0-4f89-11d3-9a0c-0305e82c3301
  From:    Alice
  To:      Bob
  Message: Hello from Go producer
=================================

And in the producer terminal, the send confirmation:

2026/05/29 10:00:10 Sent  uuid=3f2504e0-4f89-11d3-9a0c-0305e82c3301 topic=demo-kafka-topic

src="/static/images/golang-kafka-producer-consumer-with-docker/kafka-docker-go-e2e-test.png"
alt="kafka-docker-go-e2e-test"
className="mx-auto my-6 h-5/6 w-5/6 rounded-lg shadow-lg"
/>

Step 6 — Check Health Endpoints

Both services expose a /health endpoint:

# Producer health
curl http://localhost:4444/health

# Consumer health
curl http://localhost:5555/health

Both return:

{"status":"up"}

Step 7 — Graceful Shutdown

Press Ctrl+C in the consumer terminal. The signal.NotifyContext cancels the context, FetchMessage returns, and the consumer exits cleanly:

2026/05/29 10:01:00 Consumer stopped

Summary

In this blog we built two Go microservices that communicate asynchronously through Apache Kafka running in Docker:

Component	Responsibility
`docker-compose.yml`	Runs a single-node Kafka broker in KRaft mode (no ZooKeeper)
`KafkaProducer`	Marshals a `Message` to JSON and publishes it to a topic
`SendHandler`	Exposes a `GET /send` HTTP endpoint to trigger the producer
`KafkaConsumer`	Unmarshals and processes messages with manual offset commits
`processWithRetry`	Retries failed messages up to 3 times with a 1-second backoff
`sendToDLQ`	Routes exhausted messages to a dead-letter topic (`-dlt`)

The key production-ready features we added beyond a minimal example:

Manual offset commit — FetchMessage + CommitMessages ensures an offset is committed only after successful processing, giving at-least-once delivery semantics.
Retry with backoff — transient failures are retried up to 3 times before escalating to the DLQ.
Dead-letter topic — messages that exhaust all retries are forwarded to demo-kafka-topic-dlt for inspection rather than silently dropped.
Graceful shutdown — signal.NotifyContext cancels the consume loop on SIGTERM/SIGINT, preventing data loss on process stop.
Health endpoints — both services expose GET /health for Docker and orchestrator health checks.
Environment-driven config — all connection parameters (KAFKA_BROKER, KAFKA_TOPIC, etc.) are read from environment variables, making both services container-ready out of the box.

DEV Community: Azam Akram

Gzip Base64 encoder / decoder

When is this useful?

How it works

How to Use This Gzip Base64 Decoder and Encoder

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml

Your API wants JSON. Your config is YAML. Convert it here, no signup needed. https://www.solutiontoolkit.com/tools/yaml-to-json-converter #json #yaml

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml #converter

Tired of pasting JSON into random sites? Here's a free in-browser validator - nothing leaves your machine. https://www.solutiontoolkit.com/tools/validate-and-prettify-json #json #pretty #validate

Check live scores, full group stage schedule, and knockout fixtures all in one place: 👉 https://www.solutiontoolkit.com/world-cup-2026/schedule #WorldCup2026 #FIFA2026 #NextJS #SolutionToolkit #WebDev #Football

Debugging GZip Base64 compressed payloads from AWS API Gateway / Lambda

The Problem: Binary Data in Text Channels

Why APIs Combine GZip and Base64

Real-World Examples

How to Debug a Compressed Payload

Decode It Instantly

Generate MD5, SHA-1, SHA-256, and SHA-512 Hashes Instantly in Your Browser

What Is a Hash and When Do You Need One?

The Four Algorithms

What the Tool Does

How It Works

A Client-Side JWT Debugger That Runs Entirely in Your Browser

I Built a Collection of 50+ Free Developer Tools That Run Entirely in the Browser

I Built a Collection of 50+ Free Developer Tools That Run Entirely in the Browser

My Goals

What's Included?

JSON & API Tools

Encoding & Decoding

Formatting & Validation

Developer Utilities

Image Tools

What I Learned Building It

Looking for Feedback

AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)

What We'll Do

Prerequisites

Why Combine ALB with ASG?

Step 1: Create a Security Group

Step 2: Create a Launch Template

Step 3: Create an Auto Scaling Group (ASG)

Step 4: Create Target Group and Load Balancer

Create a Target Group

Create an Application Load Balancer (ALB)

Create a Listener and Link it to the Target Group

Attach the Target Group to the Auto Scaling Group

Step 5: Testing the Load Balancer

Step 6: Deleting the Setup

Conclusion

Building Kafka Producer-Consumer Using Go and Docker

Introduction

Go

Apache Kafka

Docker

Prerequisites

Download Code from Github

Project Overview

Building and Running the Application

Docker Compose for Kafka Setup

Kafka Consumer Service (Go)

go.mod

Message Model (model.go)

Kafka Consumer (consumer.go)

Application Entry Point (main.go)

Kafka Producer Service (Go)

go.mod

Message Model (model.go)

Kafka Producer (producer.go)

HTTP Handler (handler.go)

Application Entry Point (main.go)

Running the Application End-to-End

Step 1 — Start Kafka

Step 2 — Start the Consumer

Step 3 — Start the Producer

Step 4 — Send a Message

Step 5 — Observe the Consumer Logs

Step 6 — Check Health Endpoints

Step 7 — Graceful Shutdown

Summary

`go.mod`

Message Model (`model.go`)

Kafka Consumer (`consumer.go`)

Application Entry Point (`main.go`)

`go.mod`

Message Model (`model.go`)

Kafka Producer (`producer.go`)

HTTP Handler (`handler.go`)

Application Entry Point (`main.go`)