Irvan← Selected work

Jabar Digital Service · Case study

Turning distributed government data into one public data channel.

As a backend engineer, I worked on the data plumbing behind Jabar Dashboard: shaping inputs from many government sources into a central ETL pipeline that could support public dashboards and policy-facing insights.

Role: Backend engineerFocus: data pipelines & ETLJabar Digital Service

The assignment

Make data from many places behave like one dependable platform.

Product
Jabar Dashboard
Contribution
Backend ETL and read models
Primary tools
PostgreSQL, materialized views
The loaded public Jabar Dashboard landing page, showing the search experience and featured dashboards for West Java.
Jabar Dashboard after its featured content finished loading—one public entry point for exploring West Java data.

The product

A single place to explore West Java’s data.

Jabar Dashboard presents West Java’s numbers, metrics, and visualisations in one public channel. It brings together featured dashboards, current highlights across topics such as population, health, education, and industry, and map-based exploration.

For citizens and public-sector teams, the point is not merely putting charts online. It is creating a more usable path from data to analysis and better-informed policy discussions.

Visit Jabar Dashboard

Who it was built for

A shared view for the people making decisions.

The dashboard was shaped around the needs of government leaders, from heads of provincial departments (dinas) to the Governor of West Java. Alongside its public-facing role, it was intended to give leadership a clearer view of indicators across sectors and support data-informed policy discussions.

Department leaders need to understand the picture within their area of responsibility. At the provincial level, the governor needs a broader view across departments. Bringing those inputs together helps create a shared basis for reviewing conditions, discussing priorities, and coordinating next steps.

My contribution was on the backend: integrating data from multiple government sources and preparing consistent datasets for those views. That connected the pipeline work to its purpose—making fragmented records easier for decision-makers to understand and use.

01 / The system behind the screen

Many sources.
One shared foundation.

I worked on the backend journey that brings scattered government data together—so the dashboard can focus on making it useful.

Source → preparation → deliveryConceptual data flow
01 / Collect
Source system A
Source system B
Source system C

Different owners.
Different data structures.

02 / Prepare

ETL pipeline

Turn source differences into a consistent data shape.

ExtractTransformLoad
03–04 / Store & prepare reads

Shared data layer

Centralised datasets, ready to reuse.

Materialized views
05 / Serve

Public insight

Dashboard APIs.
Metrics, maps, and visualisations.

My contribution

Connecting sources, building ETL flows, and preparing PostgreSQL read models behind the public experience.

Different inputs in.Consistent data out.

Challenge

The data did not start in one clean, query-ready place.

Government data comes from many owners and systems, each with its own schema, conventions, update cadence, and level of completeness. That creates a gap between the source of a record and the public-facing view of it.

If every dashboard endpoint needs to rediscover where data lives, reshape it, and resolve the same joins at request time, the product becomes difficult to maintain and increasingly expensive to query as data grows. My responsibility was to help close that gap with a central data flow.

The result had to be understandable for teams publishing information and reliable enough that public visualisations could be backed by a consistent source of truth.

02 / The PostgreSQL decision

Materialized views

Do the heavy lifting.
Before the page loads.

With millions of records and repeated joins, the useful question became: how much work can we move out of each dashboard request?

Query source tables directlyWork repeated per request
  1. Page request
  2. Join source tables
  3. Aggregate results
  4. Response

Each visit asks the database to assemble the same derived result again.

Read a prepared resultMaterialized view
Separate refresh processSource tables → joins + aggregation → stored result
Prepared before the request
  1. Page request
  2. Read stored result
  3. Response

Dashboard requests reuse the prepared data instead of rebuilding those joins.

The benefit

Less repeated computation on the request path, especially for predictable dashboard queries over large datasets.

The trade-off

A stored snapshot is only as fresh as its last refresh. Refresh timing needs to match how current the dashboard data must be.

My backend role

Build the bridge from raw records to reusable public data.

I built and maintained ETL-oriented flows: ingest data from source systems, clean and transform it into a consistent shape, apply rules needed for downstream use, and load it into central storage for the dashboard.

I also learned and applied PostgreSQL materialized views for read-heavy dashboard data. Precomputing the joined result makes the request path much lighter than repeating the same expensive joins for every dashboard load.

  • Ingest from multiple government sources into a central workflow.
  • Standardise structures so processed data can be reliably reused.
  • Prepare shared datasets for dashboard APIs and visualisations.
  • Use materialized views for repeatable, join-heavy reads.

What this enabled

A clearer route from raw records to public insight.

01

One reusable data layer

Centralising and transforming inputs means dashboard features can build on a consistent prepared dataset instead of re-solving source differences independently.

02

Faster read paths

Precomputed materialized views reduce repeated join work for read-heavy endpoints, especially when data reaches millions of rows.

03

More maintainable publishing

Separating ETL and refresh work from API requests gives the product a cleaner operational boundary: prepare deliberately, then serve predictably.

Reflection

An API response is the last step in a much longer system.

This work changed how I think about backend development: source ownership, ingestion, validation, transformation, storage, refresh timing, and finally a request that someone can understand all matter. Making an endpoint fast is useful; making the path to that endpoint repeatable is what lets a data product keep growing.

Working with PostgreSQL materialized views made that lesson concrete. For a known dashboard read pattern, preparing the right data shape early can make the system easier to reason about and more responsive for the people using it.