Skip to main content

How I Think About Java Backend Architecture

· 6 min read
tanzhuo

I've built out a few system architectures recently, so I took the time to organize my understanding of and thinking about backend architecture.

In day-to-day development, we often ask ourselves: what kind of project structure counts as a sound architecture?

Some would say a good architecture should:

  • Reduce repetitive work for developers
  • Have a clear, easy-to-understand structure
  • Be reliably stable
  • Be easy to extend and maintain

But in reality, that's only architecture at the project level.

As the business grows, systems tend to evolve from a single-machine project into a clustered architecture, and eventually into a distributed system. Along the way, all kinds of components get introduced, such as:

  • Service registry
  • Configuration center
  • API gateway
  • Circuit breaking and degradation
  • Database and table sharding
  • Disaster recovery
  • Assorted middleware

Meanwhile, deployment evolves toward a containerized Docker + K8S stack, and the server count may grow from one or two machines to dozens or even hundreds. At that point the system is no longer a simple project — it's a full architectural system.

Architecture design spans both macro-level system design and micro-level code design.

Architecture at the code level​

At the code level, architecture means unifying development conventions and improving development efficiency. For example:

  • Automatic DTO parameter validation (AOP)
  • A unified Result response object
  • Code generation
  • Standardized Service / Mapper / Controller structure
  • Auto-generated online API documentation

It also means standardizing code organization: strictly controlled package structure, consistent class naming conventions, and sensible module boundaries.

Well-written code isn't just about efficiency — it's about other people being able to quickly understand what the code means. A good code architecture dramatically lowers maintenance costs.

Business module decomposition and system decoupling​

During system design, you need to fully understand the relationships between business domains, and use those relationships to drive module decomposition and decoupling, balancing module independence, code reuse, and system complexity.

A sound architecture should achieve:

  • Business modules that don't interfere with one another
  • Feature modules that can be maintained independently
  • Code coupling kept as low as possible

Middleware and system-level capability​

As the system scales, it typically brings in various infrastructure components, such as:

  • MQ (message queues)
  • Redis
  • NoSQL
  • ELK logging stack
  • Distributed locks
  • Distributed transactions

Architecture design requires knowing the use cases for each piece of middleware — which components to introduce under which circumstances — and allocating server resources sensibly. You also need clarity on each middleware's responsibilities, each module's boundaries, and the call relationships between services.

Database design and SQL governance​

Database design occupies a critical place in architecture. A few areas deserve particular attention.

Database design​

  • Choose column types sensibly
  • Standardize column naming conventions
  • Design indexes properly
  • Add denormalized columns where appropriate

SQL quality control​

Every SQL statement in the system deserves strict review:

  • Does it use indexes correctly?
  • Are there full table scans?
  • Are there complex, hard-to-maintain queries?

Complex SQL should be broken up where possible, and the number of rows affected per statement — along with the odds of deadlocks — should be minimized.

System performance and load testing​

Before a system goes live, it needs load testing and performance testing: simulating high-concurrency traffic, probing the servers' limits, and measuring system TPS.

At the same time, tune:

  • Server configuration
  • Container configuration
  • JVM parameters

Load testing gives you a much clearer picture of where the system's bottlenecks are.

Code quality management​

Low-quality code severely undermines system stability — abnormal CPU spikes, excessive memory usage, even outright crashes.

That calls for code quality tooling, such as:

  • FindBugs
  • SonarQube

Static analysis tools surface potential problems before they bite.

Server security design​

System security is an equally important part of architecture. Common measures include:

  • Changing default ports
  • Internal/external access whitelists
  • Regular vulnerability scans
  • Encrypting API parameters

At the API level, use HTTPS transport encryption, symmetric/asymmetric encryption, and parameter signing. Also minimize open ports, enforce strong passwords, and configure brute-force protection.

Project management and team collaboration​

Architecture isn't only a technical problem — it also covers team management and development process.

Git branch management​

Keep Git branches under control:

  • New feature work on feature branches
  • Urgent bug fixes on hotfix branches
  • The test environment on a test branch

Task management​

Distribute development tasks sensibly so workloads don't vary wildly between developers. Tools like ZenTao and Teambition help with team collaboration and task management.

Automated testing​

As the system grows, relying on manual testing alone becomes hopelessly inefficient, so an automated testing system needs to be built up incrementally.

Automated testing can:

  • Verify functionality quickly
  • Catch problems early
  • Improve system stability

Frontend/backend separation​

Frontend/backend separation is now the mainstream architecture. Frontend frameworks (Vue, for instance) have mature ecosystems covering page rendering, parameter validation, interaction logic, and animation.

With the split, the backend focuses on API development and the frontend on page interaction, while also relieving servers of static asset traffic.

Static assets and object storage​

Large volumes of static assets — images, videos, files — can be stored centrally in object storage such as OSS.

The upload flow can shift to the frontend uploading directly to OSS, with the backend only storing asset URLs and handling access control. This takes significant load off the backend servers.

Microservices and future architecture​

A system should consider microservice architecture from the very start — service registry, configuration center, service governance — and be deployable to Kubernetes for horizontal scaling.

The architecture may evolve further from there — Service Mesh, cloud-native architecture. Many large companies have already landed these, but for small and mid-sized companies, traditional microservice architecture remains the norm for now.

How an architect needs to think​

A mature architect is not just a technical implementer but a long-term planner for the system. When designing an architecture, a few angles usually deserve thought:

  • Can it support where the business is heading?
  • Is the system easy to maintain?
  • Is the technical approach stable and reliable?
  • Are the costs under control?
  • Can the team sustain it long term?

Good architecture is rarely designed in one pass — it takes shape gradually through business growth, technical evolution, and continuous refinement.

Wrapping up​

Architecture design is a complete system spanning code to systems, technology to teams. Coding standards, module decomposition, middleware selection, and database governance solve the system's own problems; security design, team collaboration, and automated testing ensure the system can evolve healthily over the long run. There's no one-size-fits-all architecture — only architecture that matches your current business scale and team capability. Rather than chasing a perfect design in one shot, leave room to evolve and let the architecture grow with the business.

COMMENTS