GitHub: https://github.com/ats1999/PgGateway

Today, if you need connection pooling over network, you deploy PgBouncer. If you need load balancing, you configure another component. If you want read/write routing, auditing, observability, security policies, or custom query handling, you often end up stitching together multiple tools , or implementing the logic inside your application.

I started PgGateway to bring these capabilities into a single, extensible platform.

PgGateway will be a PostgreSQL connection pooler, proxy, load balancer, and query router built with extensibility as a first-class goal.

Why another PostgreSQL proxy?

Projects like PgBouncer have proven that a lightweight connection pooler can dramatically improve PostgreSQL scalability without altering the infrastructure of reacrhecture of the application layer.

PgGateway isn’t trying to replace what PgBouncer does well.

Instead, it’s exploring what comes next.

The idea is to combine multiple infrastructure components into one system:

• Connection Pooling
• PostgreSQL Proxy
• Load Balancing
• Read/Write Routing
• Failover Handling
• Observability
• Extensibility

Rather than deploying multiple services for each responsibility, PgGateway aims to provide a single protocol-aware layer between applications and PostgreSQL.

GitHub: https://github.com/ats1999/PgGateway

Passwords, API keys, AWS credentials, database details, wherever it’s convenient.

The problem is simple: convenient storage isn’t always secure storage.

So I built ZeroTrust, an open-source vault designed around one idea: your sensitive data should remain encrypted wherever it is stored.

How it works

ZeroTrust encrypts your data before storing it. It uses Google Drive, only the encrypted ciphertext is uploaded, your actual secrets never leave the application in plain text.

That means your storage provider stores the data, but doesn’t need to know what’s inside it.

ZeroTrust is also open source and self-hostable, so you can inspect the code, run it yourself, and stay in control of your data.

You don’t need server, it’s serverless.

Why open source?

For a tool that handles passwords and credentials, “trust me” isn’t good enough.

You should be able to see how your data is encrypted, where it goes, and what the application does with it.

That’s why ZeroTrust is open source.

Let’s Go

• https://github.com/ats1999/ZeroTrust
• https://zero-trust-pi.vercel.app/

CAN_EDIT = true
IS_MODIFIED = false
IS_EDITED = true
USE_AFTER = false

At first glance, this seems perfectly fine. But what happens when you need to store dozens of such flags for billions of records?

Instead of storing each flag individually, you can pack all of them into a single integer using bit flags.

This technique has been used for decades in operating systems, databases, game engines, network protocols, and high-performance applications because it’s incredibly memory-efficient and fast.

Let’s see how it works.

What are Bit Flags?

A bit flag uses each individual bit inside an integer to represent one boolean value.

A binary number:

00000000

contains 8 bits.

Each bit can be either:

• 0 → false
• 1 → true

Instead of storing eight separate booleans, we can store all eight inside a single byte.

For example:

Bit Position

7 6 5 4 3 2 1 0
0 0 1 0 1 1 0 1

Suppose these represent:

If the value is

00101101

then:

• Can Read ✅
• Can Delete ✅
• Is Admin ✅
• Premium User ✅

Everything else is false.

Why Use Bit Flags?

Imagine storing permissions.

Without bit flags:

{
  "canRead": true,
  "canWrite": false,
  "canDelete": true,
  "isAdmin": true,
  "premium": false,
  "verified": true
}

That’s six separate boolean values.

With bit flags:

flags = 45

where

45 = 00101101

One integer replaces multiple booleans.

Assigning Bit Values

Each flag gets a unique power of two.

Read        = 1       (00000001)
Write       = 2       (00000010)
Delete      = 4       (00000100)
Admin       = 8       (00001000)
Premium     = 16      (00010000)
Verified    = 32      (00100000)

Notice only one bit is set in each value.

Combining Flags

Use the OR operator (|).

Java:

int permissions = READ | DELETE | VERIFIED;

Binary:

00000001
00000100
00100000
---------
00100101

Result:

37

Now 37 stores three permissions.

Checking a Flag

Use AND (&).

if ((permissions & DELETE) != 0) {
    System.out.println("Delete allowed");
}

Why?

00100101
00000100
---------
00000100

Non-zero means the bit exists.

Adding a Flag

Suppose you want to add Admin permission.

permissions |= ADMIN;

Before:

00100101

After:

00101101

Only that bit changes.

Removing a Flag

Use:

permissions &= ~ADMIN;

Example:

Before

00101101

Admin mask

00001000

Invert

11110111

AND

00100101

Admin is removed.

Toggling a Flag

Use XOR (^).

permissions ^= PREMIUM;

If Premium was OFF → it becomes ON.

If Premium was ON → it becomes OFF.

Java Example

public class PermissionDemo {

    static final int READ = 1;
    static final int WRITE = 2;
    static final int DELETE = 4;
    static final int ADMIN = 8;

    public static void main(String[] args) {

        int permissions = READ | DELETE;

        permissions |= ADMIN;

        if ((permissions & DELETE) != 0) {
            System.out.println("Delete allowed");
        }

        permissions &= ~READ;

        System.out.println(permissions);
    }
}

Memory Savings

Suppose you have:

• 32 boolean flags
• 1 billion records

Without bit flags:

32 × 1,000,000,000 = 32,000,000,000 bytes ≈ 29.8 GiB ≈ 32 GB

Using one integer:

4 bytes/record
4 × 1,000,000,000 = 4,000,000,000 bytes ≈ 3.73 GiB ≈ 4 GB

That’s an 87.5% reduction in storage for this simplified example. Actual savings depend on the language, object layout, and serialization format.

Real-World Uses

Bit flags are everywhere.

Operating Systems

File permissions

Read
Write
Execute

Linux uses bit masks extensively.

Game Development

Character abilities

Invisible
Flying
Poisoned
Shielded

One integer tracks them all.

Networking

TCP packets use bits for flags like:

• SYN
• ACK
• FIN
• RST

A few bits describe the packet state.

Databases

Instead of storing:

isDeleted
isVerified
isPremium
isAdmin

Store:

status = 41

Decode whenever needed.

Conclusion

Bit flags are one of the simplest yet most effective optimization techniques available.

They let you:

• Store dozens of boolean values in a single integer
• Reduce memory usage
• Improve cache efficiency
• Perform fast permission and state checks using bitwise operations

Whether you’re building a database schema, a game engine, an operating system, or a high-performance backend service, bit flags are a valuable tool to keep in your programming toolbox.

What is config?

Configs are set of properties which affects behaviour application at run time. For example, database urls, storage path, smtp credentials, etc. There are many different ways to supply configuration to application. But, we’ll stick to the most appropriate configuration methods in spring apps.

Ways of supplying configuration to application

Please comment if there are any other way to supply configuration

• Config files (config.json, config.yaml, application.properties)
• System environment variables
• Command line arguments
• External config server(Zookeeper, etcd, spring cloud config, AWS AppConfig)

Every approach have their own pros and cons, i’ll talk about them in minimal possible details.

Config Files

It is the easiest way to supply configuration to any application. But, it comes with risk of exposing config files to git intentionally, or unintentionally.

Think about a project which is committing config files to git, but keeping only none sensitive configuration from day one.

An intern joined team, and committed sensitive configuration to git. Or a production outage happens in the mid-night and you committed sensitive configuration to git. Now, everybody knows your database password.

Such mistakes can be avoided by not committing config files to git and adding config file path into .gitignore. Now your intern can’t commit credentials to git. But, it creates another problem. Sharing of configurations and keeping it up to date.

Assume that a new intern joined your team and he doesn’t have config file, so he couldn’t create development setup. He is reaching out to senior developers, and everybody is busy in urgent meetings. So, intern is just sitting idle.

Or someone just merged code in master which requires new configs. Production was deployed with new configs, but he forgot to inform every one in the team. You just pulled the code, but it’s no longer working in your development setup. You debugged the code for hours and then got to know that, the issue was due to missing configs.

To solve the above problem, a sample config file can be committed to git every time a new config is added into application (config.sample, application-dev.properties, config.sample.yaml etc). But, it creates maintenance problem.

If you add new config, you must have to update sample config files. If you missed doing so, your teams mates may waste hours debugging the issue which shouldn’t exist.

The best solution is to mix environment variable and config file approach, which spring boot natively supports.

# application.propertis
database.url=${DATABASE_URL}
database.password=${DATABASE_PASSWORD}

# DATABASE_URL, DATABASE_PASSWORD are name of environment variables which are injected by spring boot at run time

By config file and environment variables, we can get rid of all problems described above. No way to expose credentials to git/public. Sample config file is always maintained by default, so need to debug for hours.

System environment variables

System environment variables are the oldest way of supplying configurations before spring boot, json/yaml era. It is still widely used. It has the benefits of supplying different environment variables in different environment, e.g local, prod, CI/CD etc.

It has zero risk of exposing secrets to git or public. But, it has similar maintenance issues like config files. You need to keep a sample env file in git and make sure that it’s up to date. If you failed to do so, you’ll need to face problems described above.

There are threats associated with environment variables as well, if someone gain access to your program, then he could easily get access to all environment variables.

Command line arguments

Command line arguments are configs which are supplied at the time of starting a program. It’s good for supply some application properties, like heap memory size, etc, but not suitable for supplying entire configs.

External config server

External config servers are the components which keeps the configuration in remote location and supplies configuration on demand. It can be combined with configs file to pull only configs which are specified in config file. So, it’ll eliminate problems like missing config in sample files discussed above.

External config servers are immune to attackers gaining all credentials if they get access to your application. Credentials can be stored in encrypted format.

External config servers also have it’s own disadvantage. You need to maintain one more component in your system, it must have enough system resources to serve configs, it must be highly available, because your application depends on this.

Conclusion

If you are a small team/company and don’t have infrastructure to maintain external config server, then go with config file + environment variable approach. But, if you can afford, then go with external config file + config server.

SSE is nothing but a long running HTTP connection that can be used by server to continuously stream data to client. It uses a special MIME text/event-stream. On the server, all you need to set the following header

Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

Learn more about SSE

• https://stackoverflow.com/questions/7636165/how-do-server-sent-events-actually-work
• https://html5doctor.com/server-sent-events/
• https://html.spec.whatwg.org/multipage/server-sent-events.html#reestablish-the-connection

WebSocket

In a nutshell, WebSocket enables bidirectional, full-duplex communication between client and server over a persistent single TCP socket connection.

When to use SSE?

• When communication is uni directional(Server to Client)
• SSE is simpler to scale than WebSocket, because it uses the same old plan HTML constructs.
• When only one client is involved in any communication
• e.g notification

When to use WebSocket?

• When bi-directional communication is needed
• When multiple client are communicating together
• e.g real time chat application

Happy Coding 😆

For some applications, such as task management systems(JIRA), a human friendly identifiers are preferred.

JIRA makes it easy for us to share task with others due to its ID system. Every card in JIRA uses a numeric id that is easy to read, remember and share. We’ll try to explore similar, generic solution in this post. Scope will be limited to PostgreSQL database.

Consider we are trying to build the following Task table in PostgresSQL for JIRA. The challenge is to keep every task id unique to the board.

Method #1

• Using auto increment

Auto increment column keeps the counter unique to the table. So, every insert will get a unique counter value irrespective of the board.

To solve this problem we can keep different table for different board and have a auto increment column for task.

It works if we have a small number of board, but the solution is simply not feasible when we have thousands/millions of boards.

Method #2

• Using PostgresSQL sequence

PostgresSQL sequence aren’t tied to any table, rather they are database level counters. We can create a sequence for each board and generates counter using that sequence.

It solves our problem, but still it’s inefficient in terms of storage overhead.

Every sequence roughly takes around ~8Kb. If we have 1 million sequence, then it’ll take around ~8GB of space. Its inefficient to waste ~8GB memory just to store 1 million counters.

Method #3

• Using id table

Id table allows us to store counters and update counter. It doesn’t require additional storage.

Below query can be used to update and get the latest counter

# get next counter
UPDATE counter
SET 
  count = count+1
WHERE 
  group_name = "board.1"
RETURNING count

Conclusion

The counter table approach provides a scalable way to generate group-specific auto-incrementing IDs without excessive storage costs. It ensures efficient, readable, and shareable IDs, making it a practical solution for applications like JIRA-style task management systems.

In this blog we’ll explore what is spring cloud config, spring cloud config client/server setup, querying config server using HTTP and spring cloud config client and many more.

Happy Reading :)

Why should we use spring cloud config despite better alternatives?

There plenty other other alternatives for managing micro service configurations, for example vaultproject.io, AWS AppConfig, Apache ZooKeeper, etc. But the best thing with spring cloud config is it’s native integration with spring boot. You are no longer responsible for writing configurations inside application.properties or application.yaml.

You can share same configurations between multiple micro-services, create different set of configurations for different profile for example, production profile and development profile. You can create configurations for different git branches, for example separate configuration for development branch and feature branch. Being a central configuration system, you can share your configuration with your team in real-time.

Spring cloud config creates and abstraction layer between your micro-services and configuration storage system. It supplies configuration to your micro-services in consistent structure regardless of the underlying configuration storage.

And off course, it can be used with any other programming language not just Java(Spring Boot). It exposes a HTTP API which can be used in any programming language. In fact we have NodeJs package which integrates spring cloud config, check it out here.

What exactly spring cloud config does?

The Main thing we need to understand here is that, spring cloud config doesn’t store configurations itself. It creates an abstraction layer between your micro-services and configuration storage. Being and abstraction, you can connect it with any other storage system like MySql, AWS S3, Git Repository, Disk Files.

It allows you to fetch your config from any storage system of your choice. Update config inside your micro-service when there is any change in config, add authentication, config encryption and decryption, etc .

Spring Cloud Config — Configuration structure

Spring cloud config stores configs as key/value pairs and every pair of key/value is scoped by application, profile and label. For example see below table.

How to setup spring cloud config server with JDBC?

I am assuming that you have installed JDK, maven, MySql or PostgreSQL.

To setup spring cloud config all you need to do is add few dependencies into pom.xml and specify few properties into application.properties.

We needed the following dependencies to get started

• spring-boot-started-web — this dependency is required to serve HTTP traffic for configs query.
• spring-cloud-config-server — this dependency exposes HTTP routes to serve config.
• postgresql — this dependency helps in communicating with postgresql. If you are using anyother database, use appropriate db connector.
• spring-boot-starter-data-jdbc — this dependency will be used by spring-cloud-config-server to fetch configs from database.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.3</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-web</artifactId>
      </dependency>
      <dependency>
          <groupId>org.springframework.cloud</groupId>
          <artifactId>spring-cloud-config-server</artifactId>
      </dependency>
      <dependency>
          <groupId>org.postgresql</groupId>
          <artifactId>postgresql</artifactId>
          <scope>runtime</scope>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-data-jdbc</artifactId>
      </dependency>
</dependencies>

Create a database and table for storing configs

CREATE DATABASE config_db;

# connect to db
\c config_db

CREATE TABLE PROPERTIES(application varchar(55),profile varchar(50), label varchar(50),"KEY" varchar(255), "VALUE" text);

Spring cloud config JDBC integration requires a table named properties with application, profile, label, KEY, VALUE columns.

KEY, VALUE needs to be in uppercase in PostgreSQL, haven’t tested behaviour in other SQL servers

Know more about JDBC integration — https://docs.spring.io/spring-cloud-config/reference/server/environment-repository/jdbc-backend.html

Add below config into application.properties

spring.application.name=config-server
server.port=8888
spring.threads.virtual.enabled=true
spring.profiles.active=jdbc
spring.datasource.url=jdbc:postgresql://localhost:5432/config_db
spring.datasource.username=postgres
spring.datasource.password=rahul

spring.profiles.active=jdbc is required to tell the spring cloud config server that we are using JDBC backend for storing configs.

Querying spring cloud config server via HTTP

I am assuming that you have started config server after doing setup steps as mentioned above and server is listening on 8888.

Once spring cloud config server is started you can query server using either HTTP endpoints and via spring cloud config java client.

Let’s explore querying via HTTP methods here, we will explore integration with spring boot apps later in this blog.

application,profile,label,KEY,VALUE
account_app,dev,master,server.servlet.context-path,/account
account_app,dev,feature,server.servlet.context-path,/acc
account_app,production,master,spring.threads.virtual.enabled,true
spring_apps,dev,master,spring.datasource.username,rahul_dev
spring_apps,dev,master,spring.datasource.password,FMOxUnns7iTZlVu29GVsVCXgg
spring_apps,production,master,spring.datasource.password,CnhRa1gxUjdnb2diemZXZ05qbnlhR2pPbmF
spring_apps,production,master,spring.datasource.username,rahul_prod

You can populate above CSV data into properties table of you database. Once populated we can query config. To query config we need to specify application, profile and label.

When you make GET requests on http://localhost:8888/account_app/dev/master then we’ll get the following data for application account_app, profile dev and label master.

{
  "name": "account_app",
  "profiles": [
    "dev"
  ],
  "label": "master",
  "version": null,
  "state": null,
  "propertySources": [
    {
      "name": "account_app-dev",
      "source": {
        "server.servlet.context-path": "/account"
      }
    }
  ]
}

Often we want to have common configs across micro-services and environments. You can specify multiple comma separated applications and profiles to get combined properties like below

http://localhost:8888/account_app,spring_apps/dev,production/master

{
  "name": "account_app,spring_apps",
  "profiles": [
    "dev,production"
  ],
  "label": "master",
  "version": null,
  "state": null,
  "propertySources": [
    {
      "name": "spring_apps-production",
      "source": {
        "spring.datasource.password": "CnhRa1gxUjdnb2diemZXZ05qbnlhR2pPbmF",
        "spring.datasource.username": "rahul_prod"
      }
    },
    {
      "name": "account_app-production",
      "source": {
        "spring.threads.virtual.enabled": "true"
      }
    },
    {
      "name": "spring_apps-dev",
      "source": {
        "spring.datasource.username": "rahul_dev",
        "spring.datasource.password": "FMOxUnns7iTZlVu29GVsVCXgg"
      }
    },
    {
      "name": "account_app-dev",
      "source": {
        "server.servlet.context-path": "/account"
      }
    }
  ]
}

Often we need to override one branch config with another in development for testing. For example override configs of development branch with feature branch. Currently, it’s not supported by spring cloud config sever, but you can implement custom environment repository to achieve desired behaviour. Visit here for more information.

Integrating spring cloud config server in micro-services

I am assuming that you are using spring micro-service, for other languages and environments you can use HTTP methods or implement custom solution.

If you are using NodeJs, you can try https://www.npmjs.com/package/spring-cloud-config

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.3</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

// add this into dependencies
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

spring-cloud-starter-config is a client library that fetches config from spring cloud config server.

Add following properties into your application.properties file

spring.config.import=configserver:http://localhost:8888

# value for application
spring.cloud.config.name=spring_apps,account_app

spring.cloud.config.profile=dev,production
spring.cloud.config.label=master

Spring cloud config client maps server properties to spring Environment and PropertySource abstractions. So, you no longer need to specify properties into application.properties file.

For example, spring-kafka often needs following properties to be present in application.properties file.

spring.kafka.bootstrap-servers=localhost:9092
spring.kafka.consumer.group-id=my-group
spring.kafka.consumer.auto-offset-reset=earliest
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer

Once you have integrated spring cloud config, you can directly add them into SQL table instead of application.properties.

Reading spring cloud config programatically

You can read configs manually from spring Environment object using config key.

@RestController
@RequestMapping("/config")
public class ClientClass {
  @Autowired private Environment environment;

  @GetMapping
  public String getConfig(@RequestParam String key) {
    return environment.getProperty(key);
  }
}

// try /config?key=spring.threads.virtual.enabled

You can use @Value annotation as well to read configs

@RestController
@RequestMapping("/config")
public class ClientClass {
  @Value("${spring.threads.virtual.enabled}")
  private String isVirtualThreadEnabled;

  @GetMapping
  public String getConfig() {
    return isVirtualThreadEnabled;
  }
}

Now it’s end of the blog, hope you it helped you in any way :)