Lecture 164: Core Principles of Microservice Architecture (SLA, Independent Deployment)

Today we'll dive into the principles of microservice architecture, like Service Level Agreement (SLA) and independent deployment, and also touch on decentralized data management.

Service Level Agreement (SLA): a promise to your world

Think of an SLA as a contract between a microservice and its consumers (other services, clients, or the company as a whole). It spells out clear guarantees: how fast the service should respond, what availability it must maintain, and which reliability metrics it needs to meet. An SLA is basically the microservice's personal KPI.

For example: if you're building a payment processing service, an SLA might include requirements like:

• 99.9% uptime (no more than ~43 minutes of downtime per month).
• API response time under 200 milliseconds.
• Handle at least 1000 requests per second during peak load.

How to set an SLA?

1. Understand the business value: figure out how critical each microservice is to the business. For example, the authorization system is critical, while a recommendation service can afford to "limp" sometimes.
2. Measurable metrics: define clear metrics: response time, availability, throughput.
3. Monitoring: your monitoring system has to record SLA compliance.

Example SLA

⚙️ Payment Service:
- Availability: 99.95%
- Response time: under 250 ms for 95% of transactions
- Max recovery time after failure: 5 minutes

Remember: if one microservice breaks its SLA, it can impact the entire application ecosystem!

Independent deployment: microservices standing on their own two feet

When you build a monolith, any change often means rebuilding the whole project, running all tests, and deploying the entire thing. If your project is a couple of gigabytes and you have 200 developers in parallel teams — get ready for brutal release nights.

Microservices save you from those nightmares. Each service is a mini-app you can deploy, upgrade, and roll back independently. It's like sending in a team of special agents instead of an entire army.

How to organize independent deployment

1. Split into functional blocks. Each microservice should represent a complete piece of functionality, for example:

• Authorization service
• Payment processing service
• Notification delivery service

2. Minimize coupling between services. Use REST or async queues like Kafka. If services are too tightly coupled, you'll just bring monolith problems into the microservices world.

Example of asynchronous interaction:

@Service
public class PaymentProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public PaymentProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void notifyPaymentProcessed(String paymentId) {
        kafkaTemplate.send("payment-topic", paymentId);
    }
}

The payment service sends a message to Kafka without caring who'll consume it or when.

3. Use CI/CD. A new version of a microservice is deployed automatically after tests pass. Example CI/CD pipeline config for a microservice:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: mvn clean package
  artifacts:
    paths:
      - target/*.jar

test:
  stage: test
  script: mvn test

deploy:
  stage: deploy
  script: |
    scp target/*.jar user@server:/apps/microservice
    ssh user@server "sudo systemctl restart microservice"

Decentralized data management: no big shared databases

Data modularity is a cornerstone of microservices. Ideally, each microservice should own its own database to avoid resource contention and the risk of different services changing the same table at the same time.

Approaches to data management:

1. Data ownership per microservice Each service controls its own database. For example:
   • The orders service manages the orders and order_items tables.
   • The users service manages the users and profiles tables.
2. CQRS and Event Sourcing Use CQRS (Command Query Responsibility Segregation) to separate reads and writes. For example, a command to change an order status emits an event that another service then handles.

Example of CQRS using events:

// Sending the event
public void updateOrderStatus(Order order) {
    order.setStatus(OrderStatus.PROCESSING);
    orderRepository.save(order);
    eventPublisher.publish(new OrderUpdatedEvent(order.getId(), order.getStatus()));
}

Practical use

You've just learned how SLA, independent deployment, and data decentralization make microservices a powerful development tool. These principles give you the flexibility, scalability, and reliability modern apps need.

But remember: each of these concepts requires serious tooling. For example, to implement SLAs and decentralized data management you'll need monitoring systems like Prometheus to track performance metrics, and architectural pieces like Kafka or RabbitMQ for async communication.

Microservices helped Netflix and Uber reach global scale. Given that their success is built on SLA discipline, deployment independence, and solid data management, the same approaches can help your project too — whether it's a startup or an enterprise app.