I Stopped “Learning Cloud” and Started Thinking Like an Architect

Subhojit Ghosh — Wed, 29 Apr 2026 09:48:39 +0000

Introduction

Most cloud tutorials focus on how to deploy, but real-world engineering is about understanding why we choose certain architectures and what trade-offs we accept. To explore this properly, I set out to design a scalable, serverless backend on Google Cloud that is not just functional but production-oriented in thinking, focusing on system design, performance, and cost efficiency rather than just basic deployment.

Problem Statement

The goal was to build a backend system capable of handling HTTP requests reliably, scaling automatically under varying loads, minimizing infrastructure management, and remaining cost-efficient at low traffic while still being architecturally sound and close to production-level design principles.

Architecture Overview

The system follows a simple but effective flow where a client sends requests to a Cloud Run service, which processes them and interacts with external storage systems like Cloud Storage or Firestore, while logging and monitoring provide observability into the system’s behavior and performance.

Design Decisions

Choosing Cloud Run as the compute layer was a deliberate decision because it offers a fully managed serverless environment with automatic scaling and container-based deployment, though it comes with trade-offs like cold starts and reduced low-level control compared to virtual machines; however, the operational simplicity outweighed these concerns. A key design principle followed was statelessness, ensuring that each request is handled independently, enabling horizontal scaling and aligning naturally with serverless architecture, while all persistent state is offloaded to managed storage services to avoid tight coupling. For storage, responsibilities were separated by using Cloud Storage for unstructured data and considering Firestore for structured data, reinforcing a clean separation between compute and persistence layers. Security was handled through careful IAM configuration using the principle of least privilege, highlighting that access control is not just a setup step but a core part of system design.

Deployment & Performance

The deployment process involved containerizing a Node.js backend, pushing it to a container registry, and deploying it via Cloud Run with proper environment configurations and permissions, closely resembling real production workflows. From a performance perspective, the system scales to zero when idle, eliminating unnecessary costs, while also handling sudden traffic spikes efficiently; however, cold start latency of a few hundred milliseconds can impact responsiveness in certain scenarios, which can be optimized by maintaining a minimum number of running instances.

Cost & Trade-offs

Cost efficiency is one of the biggest advantages, as the pay-per-request model ensures resources are only billed when used, but it requires awareness because misconfigured services, excessive logging, or storage usage can increase costs. Throughout the process, trade-offs were constantly evaluated, such as choosing serverless simplicity over granular control, accepting potential latency issues for scalability, and relying on managed services at the cost of some vendor dependency, all of which are realistic considerations in modern system design.

Key Takeaways

The most important insight from this experience is that architecture matters more than individual tools, as building scalable systems requires thinking about flow, dependencies, and failure points rather than just writing code. Serverless is powerful but not magical, and simplicity in design often leads to better scalability and reliability.

Future Improvements

This system can be extended by integrating API Gateway for better request management, Pub/Sub for asynchronous processing, Cloud Build for CI/CD pipelines, and Kubernetes for more complex orchestration, making it closer to enterprise-grade architecture.

Final Thoughts

This project shifted my mindset from simply deploying applications to designing systems that are scalable, observable, and efficient, which is a crucial transition for any developer working in today’s cloud-driven world. The real value of Google Cloud lies not just in the services it offers but in how thoughtfully those services are combined to solve real problems.**

const express = require("express");
const app = express();

app.use(express.json());

app.get("/", (req, res) => {
  res.send("Serverless backend is running 🚀");
});

app.post("/data", (req, res) => {
  const data = req.body;

  // Simulate processing
  console.log("Received data:", data);

  res.json({
    status: "success",
    message: "Data processed successfully",
  });
});

const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

# Use official Node.js runtime
FROM node:18

# Set working directory
WORKDIR /app

# Copy files
COPY package*.json ./
RUN npm install

COPY . .

# Expose port
EXPOSE 8080

# Start the app
CMD ["node", "index.js"]

# Build container image
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/serverless-app

# Deploy to Cloud Run
gcloud run deploy serverless-app \
  --image gcr.io/YOUR_PROJECT_ID/serverless-app \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated

DEV Community: Subhojit Ghosh

I Stopped “Learning Cloud” and Started Thinking Like an Architect