Posts

Showing posts with the label design

Design Patterns

Image
Introduction Gang of Four (GoF) is a term referring to a group of 4 authors ( Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides ) who published the classic book Design Patterns: Elements of Reusable Object-Oriented Software in 1994 . The book summarizes 23 design patterns commonly used to solve recurring object-oriented programming ( OOP ) design problems. The main benefit of GoF Design Patterns is providing standardized solutions to common problems, making source code easier to maintain, extend and creating a common language for developers when discussing software architecture. These 23 design patterns are divided into 3 main groups: Creational Patterns Factory Method : Defines an interface for creating an object, but lets subclasses decide which class to instantiate. Abstract Factory : Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Builder : Separates the construction of a complex obj...

System Architecture Design

Image
Introduction The System Architecture Design process is a series of engineering activities aimed at transforming business requirements into a complete, optimized and scalable infrastructure and software model. The process of system architecture design steps includes: Requirement Analysis & Scope Definition This is the time for Technical Requirement Gathering & Analysis to clarify two core groups of requirements with Stakeholders and Product Team : Functional Requirements (FR) : What the system can do (such as ordering, payment, sending notifications, etc.). Non-Functional Requirements (NFR) : How the system operates (such as latency < 100ms, target QPS/RPS, 99.99% availability, OWASP/GDPR security standards, Cloud budget). Capacity Estimation & Resource Planning Preliminary calculation of operational metrics based on expected active users such as DAU (Daily Active Users) or MAU (Monthly Active Users) Traffic Estimation : Calculate average and peak reques...

Character Types

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

Effective API Design

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

RESTful API Design

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