Belajar Scala - Concurrency & Parallelism

#Pendahuluan

Setelah di episode 11 kalian memahami effect system, sekarang kita berhadapan dengan masalah tersulit dalam pemrograman: menjalankan banyak hal bersamaan. Aplikasi modern — backend service, data pipeline — tidak bisa berjalan satu langkah demi langkah; mereka harus memproses ribuan request secara paralel.

Mengapa topik ini penting? Karena concurrency adalah tempat lahirnya bug paling menyakitkan: race condition, deadlock, dan data corruption. Scala menawarkan perjalanan dari Future klasik hingga fiber yang ringan — dan pemahaman yang benar tentang keduanya akan menentukan apakah aplikasi kalian tetap sehat saat trafik naik.

#Future: Concurrency Klasik

scala.concurrent.Future adalah titik masuk concurrency paling tradisional di Scala:

import scala.concurrent.{Future, ExecutionContext}
import scala.concurrent.ExecutionContext.Implicits.global
 
val async: Future[Int] = Future {
  Thread.sleep(500)   // simulasi kerja berat
  42
}

Future { ... } menjalankan blok di thread pool (ExecutionContext) dan langsung mengembalikan nilai future — placeholder hasil yang akan datang.

#Kombinasi dengan map/flatMap

Future bisa dikomposisi seperti collection:

val result: Future[Int] =
  for
    a <- Future { 10 }
    b <- Future { 20 }
  yield a + b

Kedua Future di atas bisa berjalan paralel (jika eksekusi memungkinkan), dan hasilnya digabung tanpa blocking.

#Await: Memaksa Menunggu

Untuk program sederhana, Await memblokir sampai selesai:

import scala.concurrent.Await
import scala.concurrent.duration.*
 
val value = Await.result(result, 5.seconds)
println(value)   // 30

#Masalah Future

Future punya kelemahan struktural:

• Tidak bisa dibatalkan — begitu dibuat, ia berjalan sampai selesai (atau gagal).
• Await mencuri thread — blocking membunuh throughput.
• Error handling tersembunyi — exception di dalam Future dicatat di failure callback, mudah terlewat.
• Tidak terkait lifecycle — "future" yang tidak pernah diobservasi tetap berjalan.

Untuk program sederhana, ini cukup. Untuk aplikasi produksi, fiber adalah jawaban modern.

#Fiber: Concurrency Ringan

Fiber adalah unit komputasi yang sangat ringan — ribuan fiber bisa berjalan di atas beberapa thread. Ini beda fundamental dari Future yang 1:1 dengan thread.

import cats.effect.{IO, IOApp}
 
object Main extends IOApp.Simple:
  val run: IO[Unit] =
    for
      fiber1 <- IO.sleep(500.millis).map(_ => "tugas A").start
      fiber2 <- IO.sleep(200.millis).map(_ => "tugas B").start
      a <- fiber1.joinWithNever
      b <- fiber2.joinWithNever
      _ <- IO.println(s"$a dan $b selesai")
    yield ()

.start meluncurkan fiber; .joinWithNever menunggu hasilnya. Perbedaannya dengan Future:

• Ringan — jutaan fiber tanpa tekanan pada thread.
• Bisa dibatalkan — fiber.cancel menghentikan secara bersih.
• Structured — lifecycle fiber terikat pada scope tempat ia dibuat.

#Structured Concurrency

Prinsipnya: fiber yang dibuat di dalam scope tidak boleh hidup lebih lama dari scope-nya. Contoh dengan parTraverse yang memproses koleksi secara paralel:

import cats.effect.IO
import cats.syntax.all.*
 
val tasks: List[IO[Int]] = List(1, 2, 3, 4, 5).map(n => IO.pure(n * 10))
 
val all: IO[List[Int]] = tasks.parSequence
 
all.map(result => println(result))

parSequence menjalankan semua efek paralel dan menunggu semuanya; jika salah satu gagal, yang lain dibatalkan — perilaku terstruktur yang jauh lebih mudah dinalar daripada Future liar.

#Ref dan Queue: State Bersama yang Aman

#Ref: Mutasi Atomik

Ref adalah cell immutable yang menyediakan update atomik — pengganti var di dunia effect:

import cats.effect.{IO, Ref}
 
val program: IO[Int] =
  for
    counter <- Ref.of[IO, Int](0)
    _ <- List.fill(100)(counter.update(_ + 1)).parSequence
    value <- counter.get
  yield value   // selalu 100

100 fiber meng-update counter secara paralel, dan Ref.update menjamin tidak ada race condition — hasilnya deterministik 100.

#Queue: Komunikasi Antar Fiber

Queue menghubungkan producer dan consumer:

import cats.effect.IO
import cats.effect.std.Queue
 
val program: IO[Unit] =
  for
    queue <- Queue.unbounded[IO, Int]
    producer = (1 to 5).toList.traverse_(queue.offer)
    consumer = queue.take.flatMap(n => IO.println(s"terima: $n"))
    _ <- producer.start
    _ <- consumer.replicateA(5).start
    _ <- IO.sleep(1.second)
  yield ()

offer menaruh, take mengambil (memblokir fiber jika kosong — bukan thread!). Pola ini adalah tulang punggung pipeline streaming.

#ZIO: Fiber dan Scheduler Bawaan

ZIO juga berbasis fiber dan structured concurrency, dengan API yang sedikit berbeda:

import zio.*
 
object Main extends ZIOAppDefault:
  def run =
    for
      fiber <- ZIO.succeed("tugas berat").fork
      hasil <- fiber.join
      _ <- Console.printLine(s"hasil: $hasil")
    yield ()

fork dan join di ZIO setara dengan .start dan .join di cats-effect. ZIO juga punya ZIO.foreachPar untuk paralelisme terstruktur.

#Parallellism vs Concurrency

Dua konsep yang sering tertukar:

• Concurrency — banyak tugas dalam progres, saling berbagi waktu. Perhatian pada interleaving dan race.
• Parallelism — banyak tugas benar-benar berjalan bersamaan di banyak core. Perhatian pada pembagian kerja.

Scala mendukung keduanya: concurrency lewat fiber/future, parallelism lewat thread pool dan collection paralel (mis. .par).

#Common Pitfalls

• Await di dalam service — blokir thread = bunuh throughput. Efek harus dikomposisi tanpa blocking.
• Share mutable state tanpa Ref — var yang dibagikan antar fiber adalah undangan race condition.
• Fiber yang "bocor" — fiber yang dibuat tetapi tidak di-join dan tidak terikat scope tetap berjalan; pakai structured concurrency.
• ExecutionContext yang salah — blocking operation di thread pool CPU akan melumpuhkan semua. Pisahkan pool untuk I/O dan CPU.

#Penutup

Inti yang harus dibawa pulang:

• Future adalah concurrency klasik 1:1 dengan thread, punya masalah: tidak bisa dibatalkan, Await memblokir.
• Fiber sangat ringan dan bisa dibatalkan — fondasi concurrency modern cats-effect/ZIO.
• Structured concurrency (parSequence, foreachPar) membuat lifecycle fiber terprediksi dan aman.
• Ref untuk state atomik, Queue untuk komunikasi antar fiber.
• Concurrency (interleaving) berbeda dari parallelism (bersamaan fisik) — keduanya butuh pendekatan berbeda.

Di episode 13 selanjutnya, kita memakai semua ini untuk membangun sesuatu yang nyata: backend service dengan http4s dan Tapir — HTTP server pure functional, endpoint type-safe, dokumentasi OpenAPI, dan serialisasi JSON dengan circe. Sampai jumpa di episode 13!