Back-End Development Basics

Know your Data

It is most important for a back-end developer to understand the characteristics of the Data their software will interact with. This includes both data inflows and data outflows. Questions such as the following need to be asked:

  • How much data is incoming?
  • What is the shape/type of the data?
  • How should this data be processed?
  • Where is this data needed or useful?
  • What is the corresponding response to this type of data?
  • How soon is a response needed?

After careful deliberation and analysis, implementation details will naturally emerge regarding load balancing, API design, data structures, micro-service division of labor, parallelization of processing, replication, stream-publishing, table design, caching, relational vs key-value etc.

The data is the canonical source for developing robust back-end endpoints and services. This is relevant from the high-level architectural decisions all the way to direct coding.

For example, a service which handles low data volume, with simply query parameters, with low amounts of processing (CRUD), with no real-time requirements in response time, can and should be incredibly simple. There is no reason to over-complicate things. A basic load-balancer paired with a simple web-app and simple db is good enough (with regular backups of course).

Conversely, a service which handles billions of requests a day, with high levels of processing, and many orthogonal services waiting for the data will need specialized streams/queues, parallel processing, advanced backup systems, specialized data structures with aggressive caching.


System scaling

For high-performance, high-throughput systems, it is important to get the basics right. Paying attention to the data you are dealing with, and analyzing the space and time complexities of your algorithms is crucial.

  • Use appropriate algorithms and data structures
  • Lift load on resources as soon as possible. (Early returns, forwarding requests to relevant module, etc)
  • Check for and handle errors as early as possible. Prevent propagation of errors.
  • Find a good point of modularity (monolith vs microservices)
  • As simple as possible data distribution and replication pipeline.
  • Determine level of Data normalization (optimize for speed vs optimize for reduction of redundancy)


For large systems, it is important to build services for maintainability. This includes using:

  • Clean, clear code
  • Simple abstractions
  • Microservices for separation of concern
  • Well-defined, versioned APIS, as well as organization process for creating new endpoints
  • Re-use what you can
  • Cherry-pick suitable design patterns (SOLID, functional, etc…), do not force