Comprehensive Guide to Building a Backend Technology Stack for Startup Companies

1. Overview of Backend Technology Stack

The backend stack consists of four layers: the programming languages used (e.g., C++, Java, Go, PHP, Python, Ruby), the components such as message queues and databases, the development and release processes, and the systems that enforce those processes (e.g., CI platforms, code‑review tools).

2. System and Component Selection

2.1 Project Management / Bug Tracking

Redmine – Ruby‑based, extensible via plugins.

Phabricator – PHP‑based, originally from Facebook, includes code review and task management.

Jira – Java‑based, supports user stories, burndown charts, and extensive workflow customization.

Wukong CRM – Open‑source CRM that can be used for small‑scale B2B project tracking.

2.2 DNS Services

For domestic deployments, Alibaba Wanwang and Tencent DNSPod are the main providers; for international coverage, Amazon Route 53 is recommended.

2.3 Load Balancing (LB)

Cloud providers offer managed LB services (Alibaba SLB, Tencent CLB, Amazon ELB). In self‑hosted environments, LVS combined with Nginx is common.

2.4 Content Delivery Network (CDN)

Domestic leaders are Wangsu, Tencent Cloud, and Alibaba Cloud; globally, Amazon CloudFront and Akamai dominate. Using multiple CDNs improves coverage and provides disaster‑recovery benefits.

2.5 RPC Frameworks

Cross‑language RPC options include Thrift, gRPC, Hessian, and Hprose. Service‑governance‑focused frameworks include Dubbo, DubboX, Motan, and rpcx (Golang).

2.6 Service Discovery

etcd – distributed key‑value store used by Kubernetes and Cloud Foundry.

Consul – provides service registration, health checking, and KV storage.

Apache Zookeeper – coordination service originally from Hadoop.

2.7 Relational Databases

Traditional RDBMS: MySQL (or its community fork MariaDB). NewSQL examples: CockroachDB, TiDB, Google Spanner, and F1.

2.8 NoSQL Databases

Four major types: key‑value (Redis, Memcached), column‑family (HBase, Cassandra), document (MongoDB, CouchDB), and graph (Neo4j, JanusGraph).

2.9 Message Middleware

Used for asynchronous processing, system decoupling, and traffic shaping. Common open‑source options are compared in a matrix (e.g., RabbitMQ, Kafka, RocketMQ, etc.).

2.10 Code Management

Git is the de‑facto standard. GitLab (open‑source) combined with Gerrit provides robust code review and permission control.

2.11 Continuous Integration (CI)

Jenkins – Java‑based, extensible via plugins.

TeamCity – user‑friendly but commercial.

Strider – Node.js‑based, MongoDB‑backed.

GitLab CI – integrated with GitLab pipelines.

Travis CI – SaaS offering tightly coupled with GitHub.

Go (Cruise Control) – Go‑based CI solution.

2.12 Log System

The ELK stack (Elasticsearch, Logstash, Kibana) plus Filebeat handles collection, storage, and visualization. Nginx is often used as a reverse proxy to add basic authentication.

2.13 Monitoring

Two layers: OS‑level metrics (CPU, memory, network) and business‑level metrics (QPS, error rates). Popular tools include Zabbix, Open‑Falcon, Prometheus, and Grafana.

2.14 Configuration Management

Approaches: (1) Directly use ZooKeeper or etcd with UI/API and optional audit; (2) Push configuration files via automation tools like Puppet or Ansible.

2.15 Release / Deployment System

Typical pipeline: code → artifact → runnable service → production. Open‑source options include Walle, Piplin, or a combination of Jenkins + GitLab + Walle.

2.16 Jump Server

Jumpserver (open‑source) provides bastion‑host capabilities, session recording, and audit logs.

2.17 Machine Management

Tool choices depend on agent requirements and language ecosystem: Puppet/Chef (Ruby‑based) vs. Ansible/SaltStack (Python‑based). Ansible is favored for its agent‑less operation.

II. Startup‑Specific Choices

1. Language Selection

Prefer languages familiar to the team, with modern memory/thread management, rich open‑source ecosystems, and good hiring availability.

2. Component and Cloud Provider Selection

Choose reliable cloud vendors, mature open‑source components, and solutions proven in large‑scale internet companies.

3. Process and Standard Definition

Establish coding standards, branch policies, release procedures, operational runbooks, database access controls, alert handling, and reporting rhythms.

4. Building or Selecting Auxiliary Systems

Use open‑source projects that match the language and component choices to avoid reinventing the wheel.

5. Decision‑Making Considerations

Balance suitability, community support, talent availability, learning curve, performance, and long‑term evolution when picking technologies.

III. Cloud‑Based Backend Architecture for Startups

After component selection, a cloud‑native architecture typically includes managed DNS, LB, CDN, message queues, databases (both relational and NoSQL), monitoring (Prometheus + Grafana), logging (ELK), CI/CD pipelines, and configuration services built on etcd/ZooKeeper.

References

http://database.51cto.com/art/201109/291781.htm

https://zh.wikipedia.org/wiki/Kafka

https://prometheus.io/docs/introduction/overview/

http://deadline.top/2016/11/23/配置中心那点事/

http://blog.fit2cloud.com/2016/01/26/deployment-system.html