How To Dev

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...

Introduction Row-level locks are used to protect specific rows when data is being modified. Unlike table locks, Postgres does any row lock storage outside of RAM, writing them directly into the tuples (data rows) on the hard disk to avoid memory overflow. Differences Table-level Lock (8 modes): Protects the table schema and controls broad behaviors, such as full-table reads, table writes, or column alterations. You can imagine these 8 modes as "admission tickets" that control who can enter the building and what they can do inside. Row-level Lock (4 modes): Protects the actual data values inside specific rows to prevent two people from modifying the same record simultaneously. It is like locking individual small rooms inside the building. Connections Although Table-level Lock and Row-level Lock are two distinct sets of lock modes, they always run in parallel and support each other. When you act on a row, Postgres automatically assigns both a table lock and a row lock under...