How To Dev

Introduction Overhead When you store a text string on disk, PostgreSQL cannot simply write those raw letters. If it only did that, upon reading the data back, Postgres would not know: How many bytes long is this string? Where does it end so it can read the next data column? Is this a short string, a long string, or compressed? Therefore, Postgres must spend a few extra bytes right at the beginning of the string to record this management information. This additional consumed capacity is called Overhead, which is the accompanying management cost. Header Structure PostgreSQL uses a common format named varlena (Variable-length array) to store all string types ( TEXT, VARCHAR, BYTEA, JSONB... ). This Overhead portion varies depending on the length of the data string: Very short strings (Under 127 bytes) Overhead: 1 byte . Mechanism: Postgres uses this first 1 byte ( 8 bits ) to store 7 bits for recording the actual length of the string, and 1 bit as a flag signaling that this is a s...

Introduction When discussing designing effective APIs for production-ready, scalable and maintainable systems, we do not just talk about adhering to RESTful standards, but must approach it from a System and Developer Experience (DX) perspective. To design APIs effectively, the core principles usually applied are KISS (Keep It Simple, Stupid) and Consistency . As systems grow larger, consistency in URL design, error codes and payload handling will be the lifesaver for both Frontend and Backend teams. Below is the blueprint for effective API design divided by core pillars: Architectural Style & Protocol Selection Pick the right tool for the job REST (JSON over HTTP/1.1 or HTTP/2) : Still the default choice for public APIs and B2B integrations thanks to its popularity, ease of debugging and broad ecosystem. gRPC (Protocol Buffers over HTTP/2) : Mandatory for Inter-service communication (Internal Microservices) with benefits including low latency, robust streaming suppo...

Introduction REST (Representational State Transfer) working with JSON over HTTP/1.1 or HTTP/2 remains the default choice for public APIs and B2B integrations due to its popularity, debuggability and broad ecosystem. API Design & Resource Modeling When adopting REST , the design must maintain consistency, including the following characteristics: Resource-oriented Use plural nouns ( /api/v1/orders, /api/v1/users ). Placing actions in the URL, such as /orders/{id}/cancel , is a bad practice. Instead, use POST /orders/{id}/cancellations or PATCH /orders/{id} with a payload that updates state. Idempotency Ensure GET, PUT, DELETE are always idempotent. For POST (creating resources or processing payments), enforcing an Idempotency-Key in the Header is mandatory to prevent duplicate transactions during network glitches and client retries. Versioning Implement versioning from day one. Prefer URL Versioning (/api/v1/...) because it is explicit, easy to route at the Gateway layer (Nginx...