Infrastructure

Overview Vertical scaling grows capacity by adding more CPU/RAM to a single machine, while horizontal scaling grows capacity by adding more nodes behind a load balancer. The choice shapes your application’s architecture, failure model, and cost curve as it grows. Comparison Diagram VerticalHorizontalServerServer+CPU +RAMServer++CPU ++RAMLoad BalancerNodeNodeNode+NodeSingle node, growingMany nodes, distributed Comparison Table Aspect Vertical Scaling Horizontal Scaling Scaling mechanism Add CPU, RAM, or faster disks to one machine Add more machines/nodes to a shared pool Architecture requirement Works with any app, no code changes needed Requires stateless design, load balancing, and shared state (session store, distributed cache) Upper limit Capped by the largest hardware SKU available Effectively unbounded, limited only by orchestration and cost Downtime during scale-up Often requires reboot or migration to bigger instance New nodes join the pool live, no downtime Fault tolerance Single point of failure — one box, one crash Node failures are absorbed by the remaining pool Cost curve Price rises non-linearly at the high end (diminishing returns) Roughly linear cost per added unit of capacity Operational complexity Low — one server to patch, monitor, and secure Higher — needs service discovery, distributed monitoring, data consistency handling Typical use case Monolithic apps, relational databases, legacy systems Stateless web services, microservices, cloud-native workloads Key Differences Vertical scaling upgrades a single machine; horizontal scaling adds more machines to a pool Horizontal scaling demands stateless services, while vertical scaling needs no architectural change Vertical scaling has a hard hardware ceiling; horizontal scaling scales near-linearly A single oversized server is a single point of failure, unlike a distributed node pool Horizontal scaling trades simplicity for operational complexity in orchestration and consistency When to Use Each Vertical Scaling ...

Overview Edge computing and cloud computing both run workloads away from the end-user device, but they differ in where that processing physically happens relative to the data source. Edge computing pushes compute to nodes near the device to cut latency, while cloud computing centralizes it in remote data centers for scale and simplicity. The choice shapes latency budgets, bandwidth costs, and how much infrastructure you have to manage yourself. Comparison Diagram Where Processing HappensEdge ComputingDeviceEdgeNode~1-5 ms round tripCloud ComputingDeviceCloudDataCenter~50-150 ms round trip, multiple network hopsSame device, two distances to compute Comparison Table Aspect Edge Computing Cloud Computing Processing location Local nodes, gateways, or on-device hardware near the data source Centralized data centers operated by the provider, often far from the source Latency Single-digit to low double-digit milliseconds due to physical proximity Tens to hundreds of milliseconds depending on distance and network path Network dependency Can operate with intermittent or low-bandwidth connectivity to the core network Requires a stable, sufficiently fast connection to reach the data center Bandwidth usage Filters or pre-processes data locally, sending only summaries upstream Raw data typically travels over the network to be processed centrally Compute and storage capacity Limited by the size and power of local hardware Effectively unlimited, elastic capacity provisioned on demand Data handling and privacy Sensitive data can be processed and stay on-site, reducing exposure Data leaves the local environment and is subject to provider-side controls Scalability and management Scaling means deploying and maintaining more physical nodes across sites Scaling is a configuration change managed by the provider Cost model Upfront hardware and per-site operational costs Pay-as-you-go operating expense with no hardware to own Key Differences Edge computing minimizes latency by keeping processing physically close to the data source Cloud computing offers far greater elastic capacity since it draws on a shared, centralized pool of resources Edge deployments reduce bandwidth costs by filtering data before it ever leaves the site Cloud computing is simpler to manage since there’s no distributed hardware fleet to maintain Edge nodes can keep sensitive data local, while cloud centralization concentrates data in provider infrastructure When to Use Each Edge Computing ...

Overview A load balancer spreads incoming traffic across many identical backend servers so no single machine gets overwhelmed, while a reverse proxy sits in front of one or more servers to mediate, secure, and transform requests on their behalf. The two overlap heavily in practice — most modern reverse proxies (NGINX, Envoy, HAProxy) can also load balance — but the distinction matters when you’re deciding which capability you actually need to configure or scale for. ...

Overview A managed database hands the operating system, patching, backups, and failover to a cloud provider, while a self-hosted database keeps the entire stack under your team’s direct control. The choice trades operational convenience against flexibility, cost structure, and how much low-level tuning you’re allowed to do. Comparison Diagram Managed DatabaseSelf-Hosted DatabaseApplication / QueriesProvider ManagesDB EngineOperating SystemHardware / StorageLess control, less toilYou Manage EverythingApplication / QueriesDB EngineOperating SystemHardware / StorageMore control, more toil Comparison Table Aspect Managed Database Self-Hosted Database Provisioning & setup Spin up via console or API in minutes; provider installs and configures the engine Manually install and configure the OS, storage, and database software yourself Configuration & tuning access Limited to exposed parameters and flags; some engine internals and OS access are locked Full root or admin access to every config file, kernel setting, and storage layout Scaling Resize compute or add read replicas with a click or API call; provider automates the process Provision new hardware and reconfigure sharding or replication topology yourself Backups & recovery Automated snapshots and point-in-time restore built into the service You script, schedule, and test your own backup and restore procedures Patching & upgrades Provider applies OS and engine security patches on a maintenance schedule You plan, test, and execute every patch and major version upgrade High availability & failover Multi-AZ replication and automatic failover configured with a toggle You design, build, and test the replication and failover setup yourself Monitoring & support Built-in dashboards and alerts, plus vendor support tickets for engine-level issues You assemble your own monitoring stack; support is internal or community-based Cost model Higher per-hour price that bundles operational labor into the bill Lower raw infrastructure cost but a hidden cost in engineering time Key Differences Managed services abstract patching and OS maintenance behind a provider SLA. Self-hosted setups grant full root access to tune kernel, storage, and engine internals. Failover and multi-AZ replication are automated in managed offerings but hand-built elsewhere. Cost shifts from engineering hours to a recurring subscription fee with managed databases. Self-hosting permits any custom extension or fork that managed platforms often restrict. When to Use Each Managed Database ...

Overview Block storage exposes raw, fixed-size disk blocks to a single attached server, just like a physical hard drive — ideal for databases and boot volumes needing low-latency random reads and writes. Object storage instead organizes data as whole items with rich metadata in a flat, HTTP-accessible namespace, trading fine-grained in-place edits for virtually unlimited scale. The choice determines whether your application talks to storage like a disk or like a web API. ...

Overview Public and private cloud both deliver on-demand, virtualized IT resources, but differ in who owns and shares the underlying infrastructure. Public cloud pools shared hardware across many customers over the internet, while private cloud reserves dedicated hardware for a single organization. The choice shapes cost, control, and compliance posture. Comparison Diagram Public CloudPrivate Cloudvia Public Internetvia Private Network / VPNOrg AYouOrg BOrg CYour Org OnlyComputeStorageNetworkShared, multi-tenantDedicated, single-tenant Comparison Table Aspect Public Cloud Private Cloud Infrastructure ownership Owned and operated by a third-party provider (AWS, Azure, GCP) Owned by the organization, or a provider-managed dedicated instance Tenancy model Multi-tenant — hardware and hypervisor shared across many customers Single-tenant — hardware reserved exclusively for one organization Network access path Reached over the public internet, secured via account credentials and VPCs Reached over a private network, VPN, or dedicated leased line Provisioning and scaling Near-instant self-service scaling from a shared resource pool Scaling bounded by pre-purchased or pre-built capacity Cost structure Pay-as-you-go operating expense with no upfront hardware cost Large upfront capital expense or fixed contract, amortized over time Security and compliance control Shared responsibility model; provider secures the underlying infrastructure Full control over physical and network security, easing strict compliance audits Customization and control Limited to the services and configurations the provider exposes Full control over hardware, hypervisor, and network topology Key Differences Public cloud runs on shared infrastructure across many customers; private cloud reserves hardware for a single tenant. Public cloud follows a shared responsibility security model; private cloud gives the organization full control over the stack. Public cloud costs are operating expense, scaling with usage; private cloud typically requires capital investment upfront. Public cloud offers near-instant elastic scaling; private cloud scaling is bounded by provisioned capacity. Private cloud simplifies strict regulatory compliance; public cloud relies on provider-audited controls instead. When to Use Each Public Cloud ...

Overview Immutable infrastructure treats servers as disposable artifacts — every change ships as a brand-new image that replaces the running instance rather than editing it. Mutable infrastructure instead updates in place, applying patches and config changes directly to long-lived servers. The choice determines how predictable, auditable, and drift-resistant your environments are. Comparison Diagram Immutable InfrastructureMutable InfrastructureImage v1Server v1terminatedImage v2Server v2live trafficchange = build new image,deploy new instance, discard oldServerv1 → v1.1 → v1.2patch in placechange = SSH in / run configmanagement, edit same instance Comparison Table Aspect Immutable Infrastructure Mutable Infrastructure Initial provisioning Instance built once from a versioned image or template Instance provisioned once, then edited repeatedly over its life Applying a change Rebuild the image with the change baked in SSH in, or run a config-management tool, against the live server Deployment mechanism Orchestrator replaces old instances with new ones (rolling/blue-green) Update scripts or agents (Ansible, Chef, Puppet) mutate the running instance Configuration drift Cannot occur — every instance matches its source image exactly Accumulates over time as ad hoc changes diverge from documented state Rollback Redeploy the prior image version, deterministic and fast Manually reverse changes on the server, often incomplete or unreliable Emergency hotfixes Requires rebuilding and redeploying an image, slower to react Can be patched directly on the box in seconds Auditability & reproducibility Image is a versioned artifact; environment is fully reproducible True state only knowable by inspecting the live server Pipeline & storage overhead Needs an image build pipeline and artifact/image registry Lower tooling overhead, no build pipeline required Key Differences Immutable instances are never touched after launch; mutable servers are patched in place. Immutable infrastructure eliminates configuration drift by construction. Rolling back immutable infra just means redeploying a prior image version. Mutable infra depends on ongoing config management tooling to keep state converged. Immutable workflows require an image build pipeline and registry that mutable setups skip. When to Use Each Immutable Infrastructure ...

Overview Horizontal and vertical scaling are the two fundamental strategies for adding capacity to a system: one adds more nodes working in parallel, the other adds more resources to a single existing node. The choice shapes cost, downtime, fault tolerance, and how much your application architecture has to change to support it. Comparison Diagram Horizontal ScalingVertical ScalingLoad BalancerS1S2S3+scale out: add identical nodesno downtime, redundantServer2 CPU / 4GBSame Server16 CPU / 64GBupgradedscale up: add CPU/RAM/diskoften needs downtime Comparison Table Aspect Horizontal Scaling Vertical Scaling Mechanism Add more machines/nodes to the pool Add more CPU, RAM, or disk to an existing machine Implementation Requires a load balancer and clustering to distribute work Swap hardware or resize the VM/instance in place Downtime Typically none; new nodes join the pool live Usually requires a reboot or maintenance window Application requirements App must be stateless or handle distributed state App can remain unaware, since it still runs on one node Cost model Roughly linear cost per added commodity node Cost rises steeply at high-end hardware tiers Fault tolerance Redundant; a node failing doesn’t take the system down Single point of failure; that node failing is an outage Capacity ceiling Practically unbounded, add nodes as needed Bounded by the largest machine/instance available Typical use case Web-scale services, microservices, cloud-native apps Databases, legacy monoliths, short-term quick fixes Key Differences Horizontal scaling adds more nodes in parallel, while vertical scaling adds more resources to one existing node. Horizontal scaling needs a load balancer and app-level statelessness; vertical scaling needs no architectural change. Vertical scaling eventually hits a hardware ceiling; horizontal scaling can grow near-limitlessly. Vertical scaling usually requires downtime to resize, while horizontal scaling can add capacity live. Horizontal scaling improves fault tolerance through redundancy; vertical scaling keeps a single point of failure. When to Use Each Horizontal Scaling ...