Skip to main content

Introducing Project Astra — Building Enterprise Software from First Principles

 

Why another side project?

The internet already has thousands of CRUD tutorials.

Another Todo application won't make me a better architect.

What I really want to understand is how enterprise software is designed, evolves, fails, scales, and survives in production.

Project Astra is my attempt to learn exactly that.


Why Project Astra?

During my engineering career, I have worked across multiple domains including Full Stack Development, Cloud Migration, Azure Architecture, Infrastructure as Code, Kubernetes, and Enterprise Modernization.

One thing became increasingly clear.

Learning frameworks is easy.

Understanding software systems deeply is difficult.

Project Astra exists to bridge that gap.

The objective is not to learn another framework.

The objective is to become a better engineer.


Design Philosophy

The project will follow a few simple principles.

1. Build everything from scratch

No GitHub Copilot.

No AI generated code.

Every line of code should be understood before it is committed.

AI will be used later for comparison and review—not as the author.


2. Architecture before implementation

No IDE.

No Spring Initializr.

No React application.

The first deliverables are:

  • Business Requirements
  • Functional Requirements
  • Non Functional Requirements
  • Context Diagram
  • Component Diagram
  • Deployment Diagram
  • Data Model
  • Architecture Decision Records (ADR)

Only after understanding the system will implementation begin.


3. Think like production

Every feature will answer questions such as:

How is authentication handled?

How is authorization enforced?

How are failures logged?

How are secrets managed?

How is the application monitored?

How is the infrastructure provisioned?

How are deployments automated?


Proposed Technology Stack

Backend

  • Java
  • Spring Boot

Frontend

  • React

Infrastructure

  • Docker
  • Kubernetes
  • Terraform
  • Azure

Database

  • PostgreSQL

Future Enhancements

  • Redis
  • Kafka
  • AI Services
  • Event Driven Architecture

What I'll Share

This blog won't only contain successful implementations.

It will also document:

  • Architecture decisions
  • Design trade-offs
  • Failed experiments
  • Performance tuning
  • Security improvements
  • Production simulations
  • Debugging sessions

Engineering growth comes from understanding mistakes—not hiding them.


Long-term Vision

The purpose of Project Astra is not to finish quickly.

It is to develop the mindset of an engineer capable of designing, building, operating, and evolving enterprise systems.

If, over the next year, I become better at asking the right architectural questions, the project will already be successful.


Final Thoughts

Technology changes every few years.

Engineering principles last much longer.

Project Astra is my commitment to learning those principles through deliberate practice.

If this journey resonates with you, I'd be happy to learn together.

Comments

Popular posts from this blog

🌿 AN ARCHITECT'S FIELD GUIDE TO THE SPRING PLATFORM

Spring Forward: The Architecture-Defining Release Cycle of 2025-2026 How Spring Framework 7, Boot 4, Integration 7, Batch 6, and AI 2.0 are reshaping the way enterprise systems are designed, built, and operated — and what every tech lead needs to know before their next architecture review. The Spring ecosystem has never moved faster. Across six major projects — Framework, Boot, Integration, Batch, and AI — the teams at Broadcom have delivered what I consider the most consequential release cycle in the platform's history. This is not a changelog summary. It is an architectural assessment of what these changes mean for the systems we design, the teams we lead, and the technical decisions we will have to defend in production. 📊 Figure 1 — The Spring Platform at a Glance (2025-2026) Project Latest Version Headline Theme Key Innovations 🏗️ Spring Framework 7.0 Correct-by...

Inside the Top 5 Spring Boot Security Vulnerabilities (2026): Root Cause, Attack Surface, Patch Analysis & Mitigation

  Spring Boot remains one of the most trusted frameworks for building enterprise applications. However, even mature frameworks occasionally introduce security flaws through edge cases, configuration assumptions, or dependency interactions. This article analyzes five of the most impactful Spring Boot vulnerabilities disclosed recently—not just from a CVE perspective, but from an architect's point of view. For each vulnerability we'll cover: What was the bug? How could an attacker abuse it? (conceptually) What changed in the patch? How should enterprise teams mitigate it? 1. CVE-2026-22731 – Authentication Bypass via Health Group Path Severity: High (CVSS 8.2) What was the bug? Spring Boot Actuator allows custom health groups to be exposed under additional paths. Under specific configurations, Spring Boot generated request-matching rules that were broader than intended. As a result, protected application endpoints located beneath that path could mistakenly inherit the Actuator...

Project Aegis: From an Empty FTP Directory to a Root Shell — Exploiting vsFTPd 2.3.4 Manually

  Project Aegis | Cybersecurity Lab Sometimes the most interesting vulnerability isn't hidden in the files a service exposes. It's hidden in the service itself. During a recent Project Aegis lab session, I started with what looked like a fairly uninteresting FTP service on a deliberately vulnerable Metasploitable 2 virtual machine. Anonymous FTP login worked. The root directory appeared empty. There were no obvious files to download and nothing immediately interesting to enumerate. Yet, within the same service, I eventually obtained a root shell . The journey was a useful demonstration of a complete vulnerability-assessment workflow: reconnaissance → service identification → vulnerability research → automated validation → source inspection → manual reproduction → exploitation → impact verification Most importantly, it reinforced a lesson I want Aegis to teach: Don't just run security tools. Understand what they're actually doing. The Lab For this experiment, I used an ...