Deploy Worker ke ECS
Consumer SQS yang Reliable

API butuh latency rendah, worker butuh retry dan throughput, dan keduanya jarang punya pola beban yang sama.

Di Chapter 5 kamu sudah men-deploy Go API skincare ke ECS Fargate di belakang ALB. Sekarang giliran sisi gelapnya: pekerjaan yang tidak boleh menahan response checkout, tetapi tetap wajib selesai.

Saat pelanggan menekan bayar, API harus segera mengembalikan 201 Created. Tetapi di belakang layar ada email konfirmasi order, pemrosesan event pembayaran dari gateway (Midtrans atau Xendit), sinkronisasi inventory, dan indexing produk. Kalau semua itu dijalankan inline di handler HTTP, satu email provider yang lambat bisa membuat checkout terasa macet, dan satu kegagalan downstream bisa menggagalkan order yang sebenarnya sudah valid.

Kita memisahkan worker dari API karena karakter bebannya berbeda. API butuh latency rendah, port HTTP, dan health check ALB. Worker butuh retry, idempotency, throughput, dan observability. Menyatukannya dalam satu task ECS membuat scaling rancu: saat queue payment menumpuk, kamu terpaksa menaikkan jumlah API task padahal masalahnya ada di sisi consumer, bukan di sisi request masuk.

Worker berjalan sebagai ECS service tanpa ALB, tanpa port publik, hanya butuh akses SQS dan downstream.

Setelah API hidup di ECS, kita tambahkan service baru bernama skincare-worker. Service ini bisa memakai image yang sama dengan API, tetapi command-nya menjalankan binary worker, bukan server HTTP.

Bentuknya satu image dengan dua binary: /app/api untuk handler HTTP, /app/worker untuk consumer SQS. Task definition API menjalankan command API plus port mapping dan target group ALB. Task definition worker menjalankan command worker tanpa port mapping sama sekali, karena worker tidak menerima trafik dari internet, ia justru yang menarik pesan dari SQS.

flowchart LR
  FE["Frontend React"] -->|POST /v1/checkout| API["Go API on ECS"]
  PG["Payment Gateway"] -->|webhook| API
  API -->|SendMessage| SQS[("SQS skincare-order-events")]
  SQS -->|ReceiveMessage long polling| W1["Worker task 1"]
  SQS -->|ReceiveMessage long polling| W2["Worker task 2"]
  W1 --> DB[("RDS PostgreSQL")]
  W1 --> Email["Email provider"]
  W1 --> CW["CloudWatch Logs"]
  SQS -->|after maxReceiveCount| DLQ[("Dead-letter queue")]
  DLQ --> Alarm["CloudWatch alarm"]

Gambar 1. API hanya enqueue event, worker menarik pesan dari SQS lalu memanggil database, email provider, dan menulis log, dengan DLQ sebagai jaring pengaman.

Consumer yang benar mengikuti satu kontrak: terima pesan, proses sampai selesai, baru hapus.

Sebelum menulis satu baris Go, kunci dulu kontrak SQS-nya, karena urutan yang salah di sini menyebabkan kelas bug yang paling mahal di sistem pembayaran: pesan hilang dan event payment yang menggantung.

Alur minimal worker bukan receive lalu delete lalu process. Urutan itu berbahaya karena pesan hilang permanen jika proses gagal setelah delete. Urutan yang benar adalah receive, proses sampai selesai, baru delete. Dengan kata lain, DeleteMessage adalah commit acknowledgement: ia berarti “aku sudah benar-benar memproses ini”.

sequenceDiagram
  participant SQS as Amazon SQS
  participant W as Go Worker
  participant DB as PostgreSQL
  W->>SQS: ReceiveMessage (WaitTimeSeconds 20)
  SQS-->>W: message + receipt handle (jadi invisible)
  W->>DB: proses idempoten (payment / email)
  alt sukses
    W->>SQS: DeleteMessage(receipt handle)
  else gagal
    W-->>SQS: tidak delete
    SQS-->>SQS: pesan visible lagi setelah visibility timeout
  end

Gambar 2. DeleteMessage adalah acknowledgement dari worker ke SQS. Tanpa delete, pesan kembali untuk diproses ulang setelah visibility timeout.

API tidak menjalankan pekerjaan berat, ia hanya membuat event kecil yang stabil untuk worker.

Endpoint checkout dan webhook pembayaran tetap dimiliki API. Setelah perubahan utama tersimpan dalam transaksi database, API mengirim event ke SQS, bukan menjalankan emailnya sendiri.

Event tidak perlu membawa seluruh snapshot order. Cukup ID dan metadata minimum, lalu worker membaca data terbaru dari database memakai order_id. Event kecil lebih tahan perubahan skema dan tidak akan basi saat worker memprosesnya beberapa detik kemudian.

Di proyek skincare, harga selalu int64 rupiah (PriceRupiah), bukan float, agar tidak ada pembulatan diam-diam. Event payment membawa amount sebagai int64 itu juga.

internal/checkout/enqueue.goSalin
package checkout

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

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/sqs"
)

// QueuePublisher adalah port kecil: hanya operasi SQS yang dipakai API,
// bukan seluruh *sqs.Client. Ini idiom "accept interfaces".
type QueuePublisher interface {
	SendMessage(ctx context.Context, params *sqs.SendMessageInput, optFns ...func(*sqs.Options)) (*sqs.SendMessageOutput, error)
}

type PaymentProcessedEvent struct {
	EventID     string    `json:"event_id"`
	EventType   string    `json:"event_type"`
	OrderID     string    `json:"order_id"`
	PaymentID   string    `json:"payment_id"`
	UserID      string    `json:"user_id"`
	AmountRupiah int64    `json:"amount_rupiah"`
	CreatedAt   time.Time `json:"created_at"`
}

func EnqueuePaymentProcessed(ctx context.Context, q QueuePublisher, queueURL string, ev PaymentProcessedEvent) error {
	body, err := json.Marshal(ev)
	if err != nil {
		return fmt.Errorf("marshal payment processed event: %w", err)
	}

	_, err = q.SendMessage(ctx, &sqs.SendMessageInput{
		QueueUrl:    aws.String(queueURL),
		MessageBody: aws.String(string(body)),
	})
	if err != nil {
		return fmt.Errorf("send payment processed message: %w", err)
	}

	return nil
}

Worker Go adalah loop panjang dengan context sebagai parameter pertama, long polling, dan error sebagai nilai.

Strukturnya tetap testable. Jangan kunci kode langsung ke *sqs.Client. Terima interface kecil untuk operasi SQS yang dipakai, lalu inject handler domain. Ini idiom Go: accept interfaces, return structs.

Worker memproses pesan dalam worker pool goroutine. Channel jobs jadi buffer internal, dan beberapa goroutine memproses pesan paralel sambil loop utama tetap fokus menarik pesan baru dengan long polling.

internal/worker/sqs_worker.goSalin
package worker

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

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/sqs"
	"github.com/aws/aws-sdk-go-v2/service/sqs/types"
)

// SQSClient adalah port: hanya tiga operasi yang dipakai worker.
type SQSClient interface {
	ReceiveMessage(ctx context.Context, params *sqs.ReceiveMessageInput, optFns ...func(*sqs.Options)) (*sqs.ReceiveMessageOutput, error)
	DeleteMessage(ctx context.Context, params *sqs.DeleteMessageInput, optFns ...func(*sqs.Options)) (*sqs.DeleteMessageOutput, error)
}

// Handler adalah logika domain: memproses satu event sampai selesai.
type Handler interface {
	Handle(ctx context.Context, msg Message) error
}

type Message struct {
	EventID   string          `json:"event_id"`
	EventType string          `json:"event_type"`
	OrderID   string          `json:"order_id"`
	PaymentID string          `json:"payment_id"`
	UserID    string          `json:"user_id"`
	Raw       json.RawMessage `json:"-"`
}

type Worker struct {
	client            SQSClient
	queueURL          string
	handler           Handler
	logger            *slog.Logger
	maxMessages       int32
	waitTimeSeconds   int32
	visibilityTimeout int32
	concurrency       int
	processTimeout    time.Duration
	deleteTimeout     time.Duration
}

func New(client SQSClient, queueURL string, handler Handler, logger *slog.Logger) *Worker {
	return &Worker{
		client:            client,
		queueURL:          queueURL,
		handler:           handler,
		logger:            logger,
		maxMessages:       10,  // batch maksimum ReceiveMessage
		waitTimeSeconds:   20,  // long polling maksimum SQS
		visibilityTimeout: 120, // lebih besar dari processTimeout
		concurrency:       5,
		processTimeout:    90 * time.Second,
		deleteTimeout:     10 * time.Second,
	}
}

// Run menjalankan loop sampai context dibatalkan (SIGTERM).
func (w *Worker) Run(ctx context.Context) error {
	jobs := make(chan types.Message)
	var wg sync.WaitGroup

	// Worker pool: beberapa goroutine memproses pesan paralel.
	for i := 0; i < w.concurrency; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for sqsMsg := range jobs {
				w.handleOne(sqsMsg)
			}
		}()
	}

	for {
		select {
		case <-ctx.Done():
			w.logger.Info("worker stop polling, menunggu pesan aktif selesai")
			close(jobs)
			wg.Wait()
			return nil
		default:
		}

		out, err := w.client.ReceiveMessage(ctx, &sqs.ReceiveMessageInput{
			QueueUrl:            aws.String(w.queueURL),
			MaxNumberOfMessages: w.maxMessages,
			WaitTimeSeconds:     w.waitTimeSeconds,
			VisibilityTimeout:   w.visibilityTimeout,
		})
		if err != nil {
			if ctx.Err() != nil {
				close(jobs)
				wg.Wait()
				return nil
			}
			w.logger.Error("receive message gagal", "error", err)
			continue
		}

		for _, sqsMsg := range out.Messages {
			jobs <- sqsMsg
		}
	}
}

func (w *Worker) handleOne(sqsMsg types.Message) {
	msg, err := decodeMessage(aws.ToString(sqsMsg.Body))
	if err != nil {
		// Payload rusak: log lalu biarkan menuju DLQ via maxReceiveCount.
		w.logger.Error("decode message gagal", "error", err)
		return
	}

	// Context proses terpisah agar pesan aktif tetap punya waktu saat SIGTERM.
	processCtx, cancel := context.WithTimeout(context.Background(), w.processTimeout)
	defer cancel()

	if err := w.handler.Handle(processCtx, msg); err != nil {
		w.logger.Error("proses message gagal", "event_id", msg.EventID, "order_id", msg.OrderID, "error", err)
		return // tidak delete: SQS akan retry setelah visibility timeout
	}

	deleteCtx, cancelDelete := context.WithTimeout(context.Background(), w.deleteTimeout)
	defer cancelDelete()

	_, err = w.client.DeleteMessage(deleteCtx, &sqs.DeleteMessageInput{
		QueueUrl:      aws.String(w.queueURL),
		ReceiptHandle: sqsMsg.ReceiptHandle,
	})
	if err != nil {
		w.logger.Error("delete message gagal", "event_id", msg.EventID, "error", err)
		return
	}

	w.logger.Info("message processed", "event_id", msg.EventID, "order_id", msg.OrderID)
}

func decodeMessage(body string) (Message, error) {
	var msg Message
	if err := json.Unmarshal([]byte(body), &msg); err != nil {
		return Message{}, fmt.Errorf("decode worker message: %w", err)
	}
	msg.Raw = json.RawMessage(body)
	return msg, nil
}

cmd/worker/main.go adalah program Go biasa: setup logger JSON, load AWS config, buat client SQS, lalu jalankan loop dengan context yang mendengar SIGTERM.

cmd/worker/main.goSalin
package main

import (
	"context"
	"log/slog"
	"os"
	"os/signal"
	"syscall"

	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/sqs"

	"github.com/kamu/skincare-backend/internal/payments"
	"github.com/kamu/skincare-backend/internal/worker"
)

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil)).With(
		"service", "skincare-worker",
		"env", getenv("APP_ENV", "development"),
	)

	// signal.NotifyContext mengubah SIGTERM dari ECS jadi pembatalan context.
	ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
	defer stop()

	queueURL := os.Getenv("ORDER_EVENTS_QUEUE_URL")
	if queueURL == "" {
		logger.Error("ORDER_EVENTS_QUEUE_URL wajib diisi")
		os.Exit(1)
	}

	cfg, err := config.LoadDefaultConfig(ctx)
	if err != nil {
		logger.Error("load aws config gagal", "error", err)
		os.Exit(1)
	}

	sqsClient := sqs.NewFromConfig(cfg)
	handler := payments.NewAsyncHandler(logger)
	runner := worker.New(sqsClient, queueURL, handler, logger)

	if err := runner.Run(ctx); err != nil {
		logger.Error("worker berhenti dengan error", "error", err)
		os.Exit(1)
	}

	logger.Info("worker shutdown selesai")
}

func getenv(key, fallback string) string {
	if v := os.Getenv(key); v != "" {
		return v
	}
	return fallback
}

SQS Standard bersifat at-least-once, jadi handler payment wajib aman saat memproses event yang sama dua kali.

Inilah Student Outcome inti Chapter 6: memproses payment event dan notifikasi secara async dengan benar. Dan kebenaran di sini berarti satu hal yang tidak boleh ditawar: idempotency.

SQS Standard queue menjamin pengiriman at-least-once, bukan exactly-once. Artinya satu event payment.processed bisa sampai dua kali ke worker, entah karena retry visibility timeout atau karena duplikasi internal SQS. Tanpa perlindungan, retry yang sehat justru menyebabkan double email konfirmasi atau, jauh lebih parah, double credit ke order yang sama.

Polanya: simpan kunci unik tiap event di tabel processed_events dengan unique constraint pada event_id. Sebelum memproses, coba klaim event itu. Jika klaim gagal karena sudah ada, lewati tanpa error (anggap sudah selesai). Database yang menegakkan unique constraint, bukan kode aplikasi yang menebak.

migrations/0007_processed_events.sqlSalin
CREATE TABLE processed_events (
    event_id     TEXT PRIMARY KEY,
    event_type   TEXT NOT NULL,
    order_id     TEXT NOT NULL,
    processed_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

internal/payments/async_handler.goSalin
package payments

import (
	"context"
	"errors"
	"fmt"
	"log/slog"

	"github.com/jackc/pgx/v5"
	"github.com/jackc/pgx/v5/pgxpool"

	"github.com/kamu/skincare-backend/internal/worker"
)

// ErrAlreadyProcessed dipakai untuk menandai event yang sudah pernah diproses.
var ErrAlreadyProcessed = errors.New("event sudah diproses")

type AsyncHandler struct {
	pool   *pgxpool.Pool
	mailer Mailer
	logger *slog.Logger
}

type Mailer interface {
	SendOrderConfirmation(ctx context.Context, orderID, userID string) error
}

func NewAsyncHandler(pool *pgxpool.Pool, mailer Mailer, logger *slog.Logger) *AsyncHandler {
	return &AsyncHandler{pool: pool, mailer: mailer, logger: logger}
}

func (h *AsyncHandler) Handle(ctx context.Context, msg worker.Message) error {
	switch msg.EventType {
	case "payment.processed", "order.confirmed":
		// jenis event yang kita tangani
	default:
		// Event tak dikenal: anggap selesai, jangan retry selamanya.
		h.logger.Warn("event type tak didukung, dilewati", "event_type", msg.EventType, "event_id", msg.EventID)
		return nil
	}

	// 1. Klaim event lewat unique constraint. Duplikat = sudah diproses.
	if err := h.claimEvent(ctx, msg); err != nil {
		if errors.Is(err, ErrAlreadyProcessed) {
			h.logger.Info("event duplikat dilewati", "event_id", msg.EventID, "order_id", msg.OrderID)
			return nil
		}
		return fmt.Errorf("klaim event: %w", err)
	}

	// 2. Efek samping bisnis: kirim notifikasi setelah klaim sukses.
	if err := h.mailer.SendOrderConfirmation(ctx, msg.OrderID, msg.UserID); err != nil {
		return fmt.Errorf("kirim konfirmasi order: %w", err)
	}

	h.logger.Info("payment event diproses", "event_id", msg.EventID, "order_id", msg.OrderID)
	return nil
}

// claimEvent menyisipkan event_id. Jika sudah ada, kembalikan ErrAlreadyProcessed.
func (h *AsyncHandler) claimEvent(ctx context.Context, msg worker.Message) error {
	const q = `
		INSERT INTO processed_events (event_id, event_type, order_id)
		VALUES ($1, $2, $3)
		ON CONFLICT (event_id) DO NOTHING`

	tag, err := h.pool.Exec(ctx, q, msg.EventID, msg.EventType, msg.OrderID)
	if err != nil && !errors.Is(err, pgx.ErrNoRows) {
		return err
	}
	if tag.RowsAffected() == 0 {
		return ErrAlreadyProcessed
	}
	return nil
}

Retry sementara biar SQS yang urus, retry di dalam handler pakai backoff, kegagalan permanen jatuh ke DLQ.

Retry di SQS terjadi otomatis ketika worker gagal menghapus pesan sebelum visibility timeout habis. Worker tidak perlu sleep dan mengirim ulang pesan sendiri untuk kegagalan antar-redelivery.

Jika handler mengembalikan error dan worker tidak memanggil DeleteMessage, SQS membuat pesan terlihat lagi setelah visibility timeout, lalu menambah ReceiveCount. Setelah ReceiveCount melewati maxReceiveCount, redrive policy memindahkan pesan ke DLQ. Inilah retry tingkat-pesan yang dijamin SQS.

infra/sqs-redrive-policy.jsonSalin
{
  "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:ap-southeast-1:123456789012:skincare-order-events-dlq\",\"maxReceiveCount\":\"5\"}"
}

flowchart TD
  Recv["ReceiveMessage"] --> Proc{"Handle sukses?"}
  Proc -->|ya| Del["DeleteMessage"] --> Done["Selesai"]
  Proc -->|error transient| NoDel["Tidak delete"]
  NoDel --> Vis["Pesan visible lagi<br/>setelah visibility timeout"]
  Vis --> Count{"ReceiveCount &gt; maxReceiveCount?"}
  Count -->|belum| Recv
  Count -->|sudah| DLQ[("Dead-letter queue")]
  DLQ --> Alarm["CloudWatch alarm<br/>DLQ depth &gt; 0"]

Gambar 3. Alur retry SQS: gagal berarti tidak delete, pesan kembali sampai maxReceiveCount, lalu jatuh ke DLQ yang memicu alarm.

Ada dua tingkat retry yang perlu kamu bedakan. Tingkat pesan diurus SQS (visibility timeout plus maxReceiveCount). Tingkat operasi diurus handler: untuk satu panggilan downstream yang sering gagal sesaat, seperti email provider rate limit, retry lokal dengan exponential backoff lebih cepat dan tidak membebani siklus visibility timeout.

internal/payments/backoff.goSalin
package payments

import (
	"context"
	"time"
)

// retryWithBackoff mengulang fn dengan jeda yang membesar (250ms, 500ms, 1s).
// Hormati context: berhenti segera saat dibatalkan, mis. saat SIGTERM.
func retryWithBackoff(ctx context.Context, attempts int, fn func() error) error {
	delay := 250 * time.Millisecond
	var err error
	for i := 0; i < attempts; i++ {
		if err = fn(); err == nil {
			return nil
		}
		select {
		case <-ctx.Done():
			return ctx.Err()
		case <-time.After(delay):
			delay *= 2
		}
	}
	return err
}

Berhenti menarik pesan baru, selesaikan pesan yang sudah di tangan, baru biarkan container mati.

Saat rolling deploy, scale-in, atau penghentian task, ECS mengirim SIGTERM lalu menunggu sebelum SIGKILL. Worker harus memanfaatkan jendela itu, bukan mati di tengah memproses payment.

Di API server, graceful shutdown berarti berhenti menerima HTTP request lalu menunggu request in-flight selesai (srv.Shutdown). Di worker, artinya berhenti memanggil ReceiveMessage, lalu memberi waktu pesan yang sudah diterima untuk selesai diproses dan dihapus dari SQS. Loop di Section 5 sudah melakukan ini: saat ctx.Done(), ia menutup channel jobs dan menunggu worker pool dengan wg.Wait().

sequenceDiagram
  participant ECS as ECS Agent
  participant Main as Loop Utama
  participant Pool as Worker Pool
  participant SQS as Amazon SQS
  ECS->>Main: SIGTERM
  Main->>Main: ctx.Done(), berhenti ReceiveMessage
  Main->>Pool: close(jobs)
  Pool->>SQS: selesaikan pesan aktif, DeleteMessage
  Pool-->>Main: wg.Wait() selesai
  Main-->>ECS: proses keluar sebelum stopTimeout
  ECS->>ECS: SIGKILL hanya jika lewat stopTimeout

Gambar 4. Urutan graceful shutdown worker. Pesan yang sedang diproses tetap diselesaikan dan dihapus sebelum container benar-benar berhenti.

Mirip task definition API, tetapi tanpa portMappings, tanpa ALB, dengan IAM task role yang lebih sempit.

Satu image membawa dua binary. Task definition worker mengarahkan command ke /app/worker dan, berbeda dengan API, tidak punya portMappings maupun target group ALB.

task-definition-worker.jsonSalin
{
  "family": "skincare-worker",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/skincare-worker-task-role",
  "containerDefinitions": [
    {
      "name": "worker",
      "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/skincare-api:8f3a2c1",
      "essential": true,
      "command": ["/app/worker"],
      "stopTimeout": 120,
      "environment": [
        { "name": "APP_ENV", "value": "production" },
        { "name": "AWS_REGION", "value": "ap-southeast-1" },
        { "name": "ORDER_EVENTS_QUEUE_URL", "value": "https://sqs.ap-southeast-1.amazonaws.com/123456789012/skincare-order-events" }
      ],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/database-url-AbCdEf"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/skincare-worker",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "worker"
        }
      },
      "readonlyRootFilesystem": true
    }
  ]
}

Task role worker harus presisi. Worker hanya butuh menarik pesan, menghapusnya, membaca atribut queue, dan akses secret yang benar-benar dipakai. Jangan beri sqs:* atau resource *.

worker-task-role-policy.jsonSalin
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:DeleteMessageBatch",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:ap-southeast-1:123456789012:skincare-order-events"
    }
  ]
}

Register task definition, lalu buat ECS service tanpa load balancer, di private subnet, mulai dari satu task.

TerminalSalin
aws ecs register-task-definition \
  --cli-input-json file://task-definition-worker.json \
  --region ap-southeast-1

aws ecs create-service \
  --cluster skincare-prod \
  --service-name skincare-worker \
  --task-definition skincare-worker \
  --desired-count 1 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-private-a,subnet-private-b],securityGroups=[sg-worker],assignPublicIp=DISABLED}" \
  --region ap-southeast-1

Worker diskalakan dari panjang antrian, bukan dari CPU saja, karena bottleneck-nya sering di downstream.

Untuk worker SQS, CPU bisa rendah walau queue panjang, karena bottleneck sering ada di database, email provider, atau rate limit gateway. Metrik yang lebih dekat ke masalah adalah jumlah pesan yang menunggu diproses.

AWS menyebut ApproximateNumberOfMessagesVisible sebagai metrik backlog antrian. Pola scaling yang direkomendasikan untuk worker adalah Backlog per Task: bagi jumlah pesan visible dengan jumlah task running, lalu target tracking menjaga angka itu di nilai tertentu (misalnya 50 pesan per task). Saat backlog naik, jumlah task bertambah; saat queue kosong, task menyusut.

flowchart LR
  SQS["SQS MessagesVisible"] --> Math["backlog_per_task =<br/>MessagesVisible / RunningTaskCount"]
  Math --> TT{"&gt; target 50?"}
  TT -->|ya| Out["Scale out:<br/>tambah task worker"]
  TT -->|tidak| In["Scale in:<br/>kurangi task worker"]
  Out --> SQS
  In --> SQS

Gambar 5. Target tracking berbasis backlog per task: jumlah task worker mengikuti panjang antrian, bukan utilisasi CPU.

Daftarkan service worker sebagai scalable target lebih dulu, dengan kapasitas minimum dan maksimum.

TerminalSalin
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/skincare-prod/skincare-worker \
  --min-capacity 1 \
  --max-capacity 10 \
  --region ap-southeast-1

Kebijakan target tracking memakai metric math untuk menghitung backlog per task dari dua metrik: ApproximateNumberOfMessagesVisible (AWS/SQS) dibagi RunningTaskCount (ECS Container Insights).

worker-scaling-policy.jsonSalin
{
  "TargetValue": 50,
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 300,
  "CustomizedMetricSpecification": {
    "Metrics": [
      {
        "Id": "m1",
        "MetricStat": {
          "Metric": {
            "Namespace": "AWS/SQS",
            "MetricName": "ApproximateNumberOfMessagesVisible",
            "Dimensions": [
              { "Name": "QueueName", "Value": "skincare-order-events" }
            ]
          },
          "Stat": "Sum"
        },
        "ReturnData": false
      },
      {
        "Id": "m2",
        "MetricStat": {
          "Metric": {
            "Namespace": "ECS/ContainerInsights",
            "MetricName": "RunningTaskCount",
            "Dimensions": [
              { "Name": "ClusterName", "Value": "skincare-prod" },
              { "Name": "ServiceName", "Value": "skincare-worker" }
            ]
          },
          "Stat": "Average"
        },
        "ReturnData": false
      },
      {
        "Id": "e1",
        "Expression": "m1 / MAX([m2, 1])",
        "Label": "backlog_per_task",
        "ReturnData": true
      }
    ]
  }
}

TerminalSalin
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/skincare-prod/skincare-worker \
  --policy-name skincare-worker-backlog-per-task \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration file://worker-scaling-policy.json \
  --region ap-southeast-1

Dorong image dua-binary, buat SQS plus DLQ, register task definition worker, jalankan service, pasang scaling dan alarm.

Latihan ini mengasumsikan API skincare sudah hidup di ECS dari Chapter 5. Fokusnya menambahkan service worker yang reliable dengan retry, idempotency, dan scaling.

TerminalSalin
go get github.com/aws/aws-sdk-go-v2/config github.com/aws/aws-sdk-go-v2/service/sqs
go test ./...

docker build -t skincare-api:$(git rev-parse --short HEAD) .
docker tag skincare-api:$(git rev-parse --short HEAD) \
  123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/skincare-api:$(git rev-parse --short HEAD)
docker push 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/skincare-api:$(git rev-parse --short HEAD)

Buat DLQ lebih dulu, lalu queue utama yang menunjuk DLQ lewat redrive policy.

TerminalSalin
# 1. Buat dead-letter queue
DLQ_URL=$(aws sqs create-queue \
  --queue-name skincare-order-events-dlq \
  --query QueueUrl --output text --region ap-southeast-1)

DLQ_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$DLQ_URL" \
  --attribute-names QueueArn \
  --query "Attributes.QueueArn" --output text --region ap-southeast-1)

# 2. Buat queue utama dengan redrive ke DLQ (maxReceiveCount 5)
aws sqs create-queue \
  --queue-name skincare-order-events \
  --attributes "{\"RedrivePolicy\":\"{\\\"deadLetterTargetArn\\\":\\\"$DLQ_ARN\\\",\\\"maxReceiveCount\\\":\\\"5\\\"}\",\"VisibilityTimeout\":\"120\"}" \
  --region ap-southeast-1

Setelah service jalan, alarm DLQ adalah jaring pengaman wajib. Satu pesan di DLQ berarti ada event payment atau notifikasi yang gagal berulang dan butuh mata manusia.

TerminalSalin
aws cloudwatch put-metric-alarm \
  --alarm-name skincare-worker-dlq-not-empty \
  --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesVisible \
  --dimensions Name=QueueName,Value=skincare-order-events-dlq \
  --statistic Sum \
  --period 60 \
  --evaluation-periods 1 \
  --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --alarm-description "DLQ worker skincare berisi pesan gagal" \
  --alarm-actions arn:aws:sns:ap-southeast-1:123456789012:skincare-prod-alerts \
  --treat-missing-data notBreaching \
  --region ap-southeast-1

Worker ECS membuat backend skincare tahan spike, observable, dan bisa diskalakan mandiri.

Dengan worker SQS terpisah, checkout tetap cepat, sementara email order dan event pembayaran diproses async dengan jaminan retry, idempotency, dan scaling sendiri.

Untuk proyek online shop skincare, pola ini menjalankan email konfirmasi order, pemrosesan event payment.processed dari gateway, sinkronisasi inventory, dan indexing produk, semua tanpa menahan response checkout. Custom metric OrdersCreated dan PaymentProcessed dari Roadmap 5 mengalir lewat worker ini, dan alarm SQS backlog plus DLQ depth dari Chapter 9 menjaganya tetap sehat.