Pytania na rozmowe - Backend Developer

1. Czym rozni sie == od equals() w Javie?

• == - porownuje referencje (adresy w pamieci). Dla typow prymitywnych porownuje wartosci.
• equals() - porownuje zawartosc obiektow (jesli metoda jest nadpisana).

String a = new String("test");
String b = new String("test");

a == b;       // false - rozne obiekty w pamieci
a.equals(b);  // true - ta sama zawartosc

2. Wyjasnij roznice miedzy ArrayList a LinkedList

3. Co to jest garbage collector i jak dziala?

Garbage Collector (GC) - automatyczny mechanizm zarzadzania pamiecia, ktory usuwa nieuzywane obiekty.

Jak dziala:

1. Mark - oznacza obiekty osiagalne z "root" (zmienne lokalne, statyczne, watki)
2. Sweep - usuwa nieoznaczone obiekty
3. Compact (opcjonalnie) - defragmentuje pamiec

Generacje pamieci:

• Young Generation - nowe obiekty, czeste GC (Minor GC)
• Old Generation - dlugo zyjace obiekty, rzadsze GC (Major GC)
• Metaspace - metadane klas

Popularne algorytmy GC: G1 (domyslny od Java 9), ZGC, Shenandoah

4. Czym sa typy generyczne (generics) i dlaczego sa wazne?

Generics pozwalaja parametryzowac typy, zapewniajac bezpieczenstwo typow w czasie kompilacji.

// Bez generics - mozliwy ClassCastException w runtime
List list = new ArrayList();
list.add("tekst");
Integer num = (Integer) list.get(0); // blad w runtime!

// Z generics - blad wykryty w czasie kompilacji
List<String> list = new ArrayList<>();
list.add("tekst");
list.add(123); // blad kompilacji!

5. Wyjasnij roznice miedzy final, finally i finalize

final int MAX = 100;  // stala

try {
    // kod
} catch (Exception e) {
    // obsluga bledu
} finally {
    // zawsze sie wykona - zamkniecie zasobow
}

6. Co to jest immutability i dlaczego jest wazna?

Obiekt niemutowalny - po utworzeniu jego stan nie moze byc zmieniony.

// String jest immutable
String s = "hello";
s.toUpperCase(); // nie zmienia s, zwraca nowy obiekt

// Tworzenie immutable klasy
public final class Person {
    private final String name;

    public Person(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
    // brak setterow!
}

7. Czym różni się interfejs od klasy abstrakcyjnej?

Przykłady zastosowania klas abstrakcyjnych

• Wspólny stan: np. saldo konta w banku

  abstract class Account {
      protected BigDecimal balance;
      public Account(BigDecimal balance) { this.balance = balance; }
      public void deposit(BigDecimal amount) { balance = balance.add(amount); }
      public abstract void withdraw(BigDecimal amount);
  }
          

• Kontrola algorytmu (Template Method): np. generowanie raportu

  abstract class ReportGenerator {
      public final void generate() {
          fetchData();
          format();
          export();
      }
      protected abstract void format();
      private void fetchData() {}
      private void export() {}
  }
          

• Wspólne zależności: np. baza danych w serwisach

  abstract class BaseService {
      protected final Repository repository;
      protected BaseService(Repository repository) { this.repository = repository; }
  }
          

Przykłady zastosowania interfejsów

• Definiowanie kontraktu API: np. PaymentProcessor z metodą process(Payment)
• Klasy niepowiązane hierarchicznie, które mają wspólne zachowanie
• Elastyczne wstrzykiwanie zależności w Spring, mockowanie w testach

Podsumowanie wyboru

• Jeśli potrzebujesz: wspólnego pola, konstruktora, częściowej implementacji, kontroli przepływu → użyj klasy abstrakcyjnej
• Jeśli potrzebujesz: kontraktu, wielu implementacji, luźnego sprzężenia → użyj interfejsu
• Interfejs nie ma konstruktora – nie możesz w nim przekazać zależności

8. Wyjasnij mechanizm Stream API i podaj przyklady uzycia

Stream API (od Java 8) - deklaratywne przetwarzanie kolekcji.

List<String> names = List.of("Anna", "Jan", "Adam", "Ewa");

// Filtrowanie i mapowanie
List<String> result = names.stream()
    .filter(name -> name.startsWith("A"))
    .map(String::toUpperCase)
    .sorted()
    .collect(Collectors.toList());
// ["ADAM", "ANNA"]

// Redukcja
int sum = List.of(1, 2, 3, 4, 5).stream()
    .reduce(0, Integer::sum); // 15

// Grupowanie
Map<Integer, List<String>> byLength = names.stream()
    .collect(Collectors.groupingBy(String::length));

Operacje:

• Posrednie (lazy): filter, map, sorted, distinct
• Terminalne (uruchamiaja przetwarzanie): collect, forEach, reduce, count

9. Co to jest Optional i jak pomaga unikac NullPointerException?

Optional - kontener, ktory moze zawierac wartosc lub byc pusty.

// Zamiast zwracac null
public Optional<User> findById(Long id) {
    User user = repository.find(id);
    return Optional.ofNullable(user);
}

// Uzycie
Optional<User> userOpt = findById(1L);

// Bezpieczne pobieranie
String name = userOpt
    .map(User::getName)
    .orElse("Unknown");

// Rzucenie wyjatku jesli brak
User user = userOpt
    .orElseThrow(() -> new NotFoundException("User not found"));

// Wykonanie akcji jesli istnieje
userOpt.ifPresent(u -> System.out.println(u.getName()));

10. Czym jest Dependency Injection i jakie sa jego rodzaje?

Dependency Injection (DI) - wzorzec, w ktorym zaleznosci sa dostarczane z zewnatrz, zamiast byc tworzone wewnatrz klasy.

// 1. Constructor Injection (ZALECANY)
@Service
public class OrderService {
    private final ProductRepository repository;

    public OrderService(ProductRepository repository) {
        this.repository = repository;
    }
}

// 2. Setter Injection
@Service
public class OrderService {
    private ProductRepository repository;

    @Autowired
    public void setRepository(ProductRepository repository) {
        this.repository = repository;
    }
}

// 3. Field Injection (NIEZALECANY)
@Service
public class OrderService {
    @Autowired
    private ProductRepository repository;
}

11. Roznice miedzy @Component, @Service, @Repository i @Controller

Wszystkie sa specjalizacjami @Component i oznaczaja bean zarzadzany przez Springa.

12. Jak dziala Spring Security? Co to jest SecurityFilterChain?

Spring Security dziala jako lancuch filtrow przechwytujacych zadania HTTP.

Glowne filtry:

1. SecurityContextPersistenceFilter - laduje kontekst bezpieczenstwa
2. UsernamePasswordAuthenticationFilter - obsluguje login
3. BasicAuthenticationFilter - HTTP Basic Auth
4. BearerTokenAuthenticationFilter - JWT
5. ExceptionTranslationFilter - obsluga wyjatkow
6. AuthorizationFilter - sprawdzanie uprawnien

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()))
            .build();
    }
}

13. Czym rozni sie @RestController od @Controller?

// @Controller - zwraca nazwy widokow (MVC)
@Controller
public class WebController {

    @GetMapping("/home")
    public String home(Model model) {
        model.addAttribute("message", "Hello");
        return "home"; // szuka templates/home.html
    }

    @GetMapping("/api/data")
    @ResponseBody // potrzebne do zwrocenia JSON
    public Data getData() {
        return new Data();
    }
}

// @RestController = @Controller + @ResponseBody na kazdej metodzie
@RestController
public class ApiController {

    @GetMapping("/api/data")
    public Data getData() {
        return new Data(); // automatycznie serializowane do JSON
    }
}

14. Wyjasnij cykl zycia beana w Springu

@Component
public class MyBean {

    @PostConstruct
    public void init() {
        // wykonywane po utworzeniu beana i wstrzyknieciu zaleznosci
    }

    @PreDestroy
    public void cleanup() {
        // wykonywane przed zniszczeniem beana
    }
}

15. Co to jest @Transactional i jak dziala propagacja transakcji?

@Transactional - zarzadza transakcjami deklaratywnie (przez AOP proxy).

@Service
public class OrderService {

    @Transactional
    public void createOrder(Order order) {
        // wszystko w jednej transakcji
        orderRepository.save(order);
        inventoryService.decreaseStock(order.getItems());
        // jesli wystapi wyjatek - rollback calosci
    }
}

15a. Inne wlasciwosci adnotacji @Transactional

Oprocz propagacji i poziomu izolacji, @Transactional posiada kilka niezaleznych wlasciwosci, ktore wplywaja na zachowanie transakcji.

16. Jak skonfigurowalbys polaczenie z baza danych w Spring Boot?

# application.yml
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: ${DB_USERNAME:admin}
    password: ${DB_PASSWORD:secret}
    driver-class-name: org.postgresql.Driver
    hikari:
      maximum-pool-size: 10
      minimum-idle: 5
      idle-timeout: 300000

  jpa:
    hibernate:
      ddl-auto: validate  # none, validate, update, create, create-drop
    show-sql: false
    properties:
      hibernate:
        format_sql: true
        dialect: org.hibernate.dialect.PostgreSQLDialect

16b. Kluczowe elementy JPA (Java Persistence API)

JPA to specyfikacja Javy do mapowania obiektowo-relacyjnego (ORM). Hibernate jest jej najpopularniejszą implementacją.

Entity

Reprezentuje tabelę w bazie danych. Każda instancja to jeden wiersz.

@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
}

EntityManager

Główny interfejs do operacji na encjach (zarządza cyklem życia obiektów):

entityManager.persist(user);     // INSERT - zapisuje nowy obiekt
entityManager.merge(user);       // UPDATE - aktualizuje odłączony obiekt
entityManager.remove(user);      // DELETE - usuwa obiekt
entityManager.find(User.class, id); // SELECT - znajduje po kluczu głównym

Stany encji (Persistence Context)

Co robi Hibernate pod spodem

Hibernate jako implementacja JPA:

• Generuje SQL — na podstawie adnotacji i konfiguracji
• Mapuje rekordy → obiekty — automatyczna konwersja ResultSet na encje
• Zarządza cache — cache 1. poziomu (per EntityManager) i opcjonalny cache 2. poziomu (współdzielony)
• Dirty checking — automatycznie wykrywa zmiany w managed entities i generuje UPDATE
• Lazy loading — ładuje relacje dopiero przy pierwszym dostępie

17. Czym rozni sie INNER JOIN od LEFT JOIN?

-- INNER JOIN - tylko pasujace rekordy z obu tabel
SELECT c.name, o.amount
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id;
-- Zwraca tylko klientow, ktorzy maja zamowienia

-- LEFT JOIN - wszystkie z lewej + pasujace z prawej
SELECT c.name, o.amount
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id;
-- Zwraca WSZYSTKICH klientow, nawet bez zamowien (amount = NULL)

18. Co to sa indeksy i kiedy warto je stosowac?

Indeks - struktura danych przyspieszajaca wyszukiwanie (najczesciej B-tree).

-- Tworzenie indeksu
CREATE INDEX idx_customer_email ON customers(email);

-- Indeks zlozony
CREATE INDEX idx_order_customer_date ON orders(customer_id, created_at);

-- Indeks unikalny
CREATE UNIQUE INDEX idx_user_username ON users(username);

19. Wyjasnij wlasciwosci ACID

20. Czym rozni sie baza SQL od NoSQL?

21. Co to jest N+1 problem i jak go rozwiazac?

Problem N+1 - wykonanie 1 zapytania po liste + N zapytan po powiazane dane.

// Problem: 1 zapytanie po zamowienia + N zapytan po klientow
List<Order> orders = orderRepository.findAll();
for (Order order : orders) {
    System.out.println(order.getCustomer().getName()); // kazde wywolanie = nowe zapytanie!
}

Rozwiazania:

// 1. JOIN FETCH (JPQL)
@Query("SELECT o FROM Order o JOIN FETCH o.customer")
List<Order> findAllWithCustomers();

// 2. @EntityGraph
@EntityGraph(attributePaths = {"customer"})
List<Order> findAll();

// 3. @BatchSize (Hibernate)
@ManyToOne
@BatchSize(size = 25) // laduje klientow partiami po 25
private Customer customer;

22. Wyjasnij poziomy izolacji transakcji

Problemy:

• Dirty Read - odczyt niezatwierdzonych danych z innej transakcji
  Przyklad: Transakcja A aktualizuje saldo konta z 1000 na 500 (ale jeszcze nie commituje). Transakcja B odczytuje saldo = 500. Nastepnie Transakcja A wykonuje ROLLBACK. Transakcja B uzywa wartosci 500, ktora nigdy nie zostala zatwierdzona - to "brudny odczyt".
• Non-repeatable Read - ten sam SELECT zwraca rozne wartosci w tej samej transakcji
  Przyklad: Transakcja A odczytuje cene produktu = 100 zl. W miedzyczasie Transakcja B zmienia cene na 150 zl i commituje. Transakcja A ponownie odczytuje cene tego samego produktu i dostaje 150 zl - rozna wartosc niz za pierwszym razem.
• Phantom Read - pojawiaja sie lub znikaja wiersze pasujace do warunku WHERE
  Przyklad: Transakcja A wykonuje SELECT COUNT(*) FROM zamowienia WHERE status='nowe' - wynik: 10. W miedzyczasie Transakcja B dodaje nowe zamowienie ze statusem 'nowe' i commituje. Transakcja A ponownie wykonuje ten sam SELECT - wynik: 11. Pojawil sie "fantomowy" wiersz.

22a. Jak faktycznie dzialaja poziomy izolacji? (co blokuje baze i co widzi transakcja)

Poziomy izolacji okreslaja jak bardzo transakcje sa od siebie odseparowane oraz jakie mechanizmy kontroli wspolbieznosci stosuje baza (MVCC, locki, snapshoty).

W PostgreSQL (i wiekszosci nowoczesnych baz) dominuje MVCC – Multi Version Concurrency Control, czyli baza nie blokuje odczytow, tylko przechowuje wiele wersji wierszy.

READ UNCOMMITTED

W teorii: mozna czytac dane jeszcze przed COMMIT-em.

W praktyce (PostgreSQL): ten poziom NIE istnieje – jest mapowany do READ COMMITTED, poniewaz Postgres nigdy nie pozwala na dirty read.

Co widzi transakcja?
Kazdy SELECT widzi tylko dane zatwierdzone przed rozpoczeciem zapytania.

Problem:
Dwa SELECT-y w tej samej transakcji moga zwrocic inne wyniki.

Kiedy uzywac?
W praktyce – nigdy jako swiadomy wybor.

READ COMMITTED (domyslny w PostgreSQL)

Jak to dziala?

• kazde zapytanie dostaje swoj "snapshot" bazy
• widzi tylko dane zatwierdzone przed startem konkretnego SELECT-a
• nie widzi zmian innych transakcji w trakcie ich trwania

Ale!
Jesli inna transakcja zrobi COMMIT pomiedzy Twoimi SELECT-ami — kolejny SELECT zobaczy nowe dane.

Co NIE jest blokowane?

• odczyty prawie nigdy nie blokuja zapisow
• zapisy blokuja tylko ten sam wiersz

Zalety:

• bardzo wysoka wydajnosc
• minimalna liczba lockow
• najlepszy wybor dla wiekszosci systemow backendowych

Wady:

• mozliwy non-repeatable read
• mozliwy phantom read

Typowe zastosowania:

• REST API
• systemy zamowien
• CRUD
• mikroserwisy

Senior tip:
~90% aplikacji produkcyjnych dziala na READ COMMITTED.

REPEATABLE READ

Kluczowa roznica:
Snapshot tworzony jest raz – na poczatku transakcji.

Oznacza to:

• kazdy SELECT zobaczy dokladnie te same dane
• nawet jesli inne transakcje zrobia COMMIT

Co blokuje baza?
Nie blokuje odczytow – nadal korzysta z MVCC.
Ale przy zapisie moze dojsc do:

• serialization failure
• could not serialize access due to concurrent update

Baza wtedy zabija jedna z transakcji.

Bardzo wazne:
W PostgreSQL phantom read praktycznie nie wystepuje na tym poziomie, poniewaz snapshot jest stabilny.

Kiedy uzywac?

• raporty finansowe
• operacje "read → decision → write"
• logika zaleznosci od wielu SELECT-ow

Minus:
wieksze ryzyko rollbackow przy duzej konkurencji.

SERIALIZABLE (najwyzszy poziom)

Cel:
Zachowanie jakby transakcje wykonywaly sie jedna po drugiej.

Jak robi to Postgres?
Nie przez ciezkie locki — tylko przez wykrywanie konfliktow (SSI – Serializable Snapshot Isolation).

Jesli baza wykryje niebezpieczna zaleznosc:

ERROR: could not serialize access due to read/write dependencies

Jedna transakcja musi zostac powtorzona.

Zalety:

• brak dirty / non-repeatable / phantom
• najwyzsza spojnosc danych

Wady:

• duzo rollbackow przy ruchu
• nizsza przepustowosc
• wymaga retry logic w aplikacji

Kiedy uzywac?

• bankowosc
• ledger / ksiega transakcji
• systemy rozliczeniowe
• krytyczne operacje finansowe

Jak to zapamietac (intuicyjnie)?

• READ COMMITTED → "widze to co juz zatwierdzone"
• REPEATABLE READ → "moja baza nie zmienia sie w trakcie transakcji"
• SERIALIZABLE → "udajemy brak wspolbieznosci"

Bardzo wazne pytanie rekrutacyjne

Czy wyzszy poziom izolacji zawsze jest lepszy?
👉 Nie.

To zawsze trade-off:

• wiecej izolacji = mniej concurrency
• wiecej rollbackow
• gorsza wydajnosc

Dlatego:
Najpierw wybieramy mozliwie najnizszy poziom, ktory nadal gwarantuje poprawna logike biznesowa.

22b. Co to jest MVCC (Multi-Version Concurrency Control)?

MVCC (Multi-Version Concurrency Control) - mechanizm umozliwiajacy wspolbiezny dostep do bazy danych poprzez przechowywanie wielu wersji danych. Transakcje dzialaja na podstawie migawki (snapshot) bazy danych.

Jak dziala MVCC (PostgreSQL):

Przyklad - UPDATE w MVCC:

-- Stan poczatkowy (transakcja 10 utworzyla wiersz)
-- id=1 | status=NEW | xmin=10 | xmax=NULL

-- Transakcja 20 wykonuje UPDATE:
UPDATE orders SET status = 'PAID' WHERE id = 1;

-- MVCC tworzy NOWA wersje wiersza (nie nadpisuje starej!):
-- id=1 | status=NEW  | xmin=10 | xmax=20   ← stara wersja (oznaczona jako usunieta przez tx 20)
-- id=1 | status=PAID | xmin=20 | xmax=NULL ← nowa wersja (utworzona przez tx 20)

-- Transakcja 15 (rozpoczeta PRZED tx 20) nadal widzi:
-- id=1 | status=NEW  (bo xmin=10 < 15, xmax=20 > 15)

-- Transakcja 25 (rozpoczeta PO tx 20) widzi:
-- id=1 | status=PAID (bo xmin=20 < 25, xmax=NULL)

Zalety MVCC:

MVCC vs tradycyjne blokowanie:

-- PostgreSQL: Reczne czyszczenie starych wersji
VACUUM orders;

-- Automatyczne czyszczenie (domyslnie wlaczone)
-- autovacuum dziala w tle

23. Jakie sa glowne metody HTTP i do czego sluza?

Metody HTTP - opisy i typowe odpowiedzi:

Charakterystyka metod:

Idempotentna - wielokrotne wywolanie daje ten sam efekt co pojedyncze (mozna bezpiecznie ponowic przy timeout).
Bezpieczna - nie zmienia stanu serwera, tylko odczytuje dane. Kazda metoda bezpieczna jest tez idempotentna.

24. Czym rozni sie PUT od PATCH?

// Zasob poczatkowy
{
  "id": 1,
  "name": "Jan Kowalski",
  "email": "jan@example.com",
  "phone": "123456789"
}

// PUT /users/1 - zastepuje CALY zasob
// Musisz wyslac wszystkie pola!
{
  "name": "Jan Nowak",
  "email": "jan@example.com",
  "phone": "123456789"
}

// PATCH /users/1 - aktualizuje TYLKO podane pola
{
  "name": "Jan Nowak"
}
// Pozostale pola (email, phone) pozostaja bez zmian

25. Jak zaprojektowalbys REST API dla sklepu internetowego?

# Produkty
GET    /api/products                    # lista produktow (z paginacja)
GET    /api/products/{id}               # szczegoly produktu
POST   /api/products                    # dodaj produkt (admin)
PUT    /api/products/{id}               # aktualizuj produkt
DELETE /api/products/{id}               # usun produkt

# Kategorie
GET    /api/categories                  # lista kategorii
GET    /api/categories/{id}/products    # produkty w kategorii

# Koszyk
GET    /api/cart                        # zawartosc koszyka
POST   /api/cart/items                  # dodaj do koszyka
PUT    /api/cart/items/{productId}      # zmien ilosc
DELETE /api/cart/items/{productId}      # usun z koszyka

# Zamowienia
GET    /api/orders                      # historia zamowien
GET    /api/orders/{id}                 # szczegoly zamowienia
POST   /api/orders                      # zloz zamowienie

# Filtrowanie i paginacja
GET /api/products?category=electronics&minPrice=100&page=0&size=20&sort=price,asc

26. Kody statusu HTTP - przyklady

1xx - Informacyjne:

2xx - Sukces:

3xx - Przekierowania:

4xx - Blad klienta:

5xx - Blad serwera:

27. Jak zabezpieczysz API? (JWT, OAuth2, API keys)

1. JWT (JSON Web Token):

// Struktura: header.payload.signature

@PostMapping("/login")
public TokenResponse login(@RequestBody LoginRequest request) {
    // 1. Weryfikacja credentials
    // 2. Generowanie JWT
    String token = Jwts.builder()
        .setSubject(user.getUsername())
        .setExpiration(new Date(System.currentTimeMillis() + 86400000))
        .signWith(secretKey)
        .compact();
    return new TokenResponse(token);
}

// Klient wysyla: Authorization: Bearer <token>

Dodatkowe zabezpieczenia: HTTPS, Rate limiting, Input validation, CORS configuration, Audit logging

28. Co to jest CORS i jak go skonfigurowac?

CORS (Cross-Origin Resource Sharing) - mechanizm pozwalajacy na zadania z innej domeny niz serwer.

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
            .allowedOrigins("http://localhost:3000", "https://myapp.com")
            .allowedMethods("GET", "POST", "PUT", "DELETE")
            .allowedHeaders("*")
            .allowCredentials(true)
            .maxAge(3600);
    }
}

29. Czym rozni sie architektura monolityczna od mikroserwisow?

30. Jak mikroserwisy komunikuja sie ze soba?

// Producer - Kafka
@Service
public class OrderService {
    private final KafkaTemplate<String, OrderEvent> kafka;

    public void createOrder(Order order) {
        orderRepository.save(order);
        kafka.send("order-events", new OrderCreatedEvent(order));
    }
}

// Consumer w innym serwisie
@KafkaListener(topics = "order-events")
public void handleOrderCreated(OrderCreatedEvent event) {
    sendEmail(event.getCustomerEmail());
}

31. Co to jest API Gateway i jaka pelni role?

API Gateway - punkt wejscia do systemu mikroserwisow.

Funkcje: Routing, Load balancing, Authentication, Rate limiting, Caching, SSL termination, Request/Response transformation

32. Jak obsluzys transakcje rozproszone? (Saga pattern)

W mikroserwisach nie ma wspolnej transakcji - kazdy serwis ma wlasna baze.

Saga Pattern

Saga Pattern - sekwencja lokalnych transakcji z kompensacjami (Eventual Consistency).

Implementacje: Choreography (zdarzenia) lub Orchestration (centralny koordynator)

Alternatywy dla Saga Pattern

1. Two-Phase Commit (2PC) - protokol zapewniajacy ACID w transakcjach rozproszonych.

// Przyklad z Atomikos (JTA Transaction Manager)
@Bean
public JtaTransactionManager transactionManager() {
    return new JtaTransactionManager(
        new UserTransactionManager()
    );
}

@Transactional(transactionManager = "jtaTransactionManager")
public void createOrder(OrderRequest request) {
    productRepo.reserve(request);   // XA Resource 1
    orderRepo.save(order);           // XA Resource 2
    paymentRepo.create(payment);    // XA Resource 3
    // Automatyczny COMMIT lub ROLLBACK przez Atomikos
}

2. TCC (Try-Confirm-Cancel) - wzorzec z rezerwacja zasobow (soft-lock).

Porownanie wzorcow

Kiedy uzywac:

• Saga - mikroserwisy, dlugie transakcje, wysoka dostepnosc
• 2PC - silna spojnosc wymagana, malo uczestnikow, krotkie transakcje
• TCC - rezerwacje zasobow, wymaga soft-lock semantyki

33. Co to jest service discovery?

Service Discovery - mechanizm automatycznego wykrywania lokalizacji serwisow.

Narzedzia: Netflix Eureka, Consul, Kubernetes DNS

# application.yml serwisu
eureka:
  client:
    serviceUrl:
      defaultZone: http://eureka:8761/eureka/

// Wywolanie po nazwie serwisu (nie IP)
restTemplate.getForObject("http://product-service/api/products/1", Product.class);

34. Jak monitorowac mikroserwisy? (logi, metryki, tracing)

Trzy filary obserwowalnosci:

1. Logi (co sie wydarzylo) - ELK Stack / Loki + Grafana
2. Metryki (ile/jak szybko) - Prometheus + Grafana
3. Tracing (sciezka zadania przez serwisy) - Zipkin / Jaeger

# Spring Boot Actuator + Micrometer
management:
  endpoints:
    web:
      exposure:
        include: health, metrics, prometheus
  metrics:
    export:
      prometheus:
        enabled: true

35. Czym jest Docker i jakie problemy rozwiazuje?

Docker - platforma do konteneryzacji aplikacji.

Problemy ktore rozwiazuje:

• "U mnie dziala" - identyczne srodowisko dev/staging/prod
• Konflikty zaleznosci - izolacja (rozne wersje Java w roznych kontenerach)
• Skomplikowana instalacja - docker run zamiast instalacji
• Skalowanie - latwe uruchomienie wielu instancji

36. Czym rozni sie obraz od kontenera?

37. Do czego sluzy docker-compose?

Docker Compose - narzedzie do definiowania i uruchamiania wielu kontenerow.

# docker-compose.yml
version: '3.8'

services:
  product-service:
    build: ./services/product-service
    ports:
      - "8081:8080"
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/products
    depends_on:
      - db

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

38. Jak zoptymalizujesz Dockerfile?

# Stage 1: Build
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app

# Najpierw kopiuj tylko pliki zaleznosci (lepszy cache)
COPY pom.xml .
COPY .mvn .mvn
COPY mvnw .
RUN ./mvnw dependency:go-offline

# Potem kod zrodlowy
COPY src ./src
RUN ./mvnw package -DskipTests

# Stage 2: Runtime (mniejszy obraz)
FROM eclipse-temurin:21-jre
WORKDIR /app

# Non-root user
RUN addgroup --system app && adduser --system --group app
USER app

COPY --from=builder /app/target/*.jar app.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

39. Czym rozni sie test jednostkowy od integracyjnego?

40. Do czego sluzy Mockito?

Mockito - biblioteka do tworzenia mockow (atrap) obiektow w testach.

@ExtendWith(MockitoExtension.class)
class ProductServiceTest {

    @Mock
    private ProductRepository productRepository;

    @InjectMocks
    private ProductService productService;

    @Test
    void shouldReturnProduct() {
        // given - konfiguracja mockow
        Product product = new Product(1L, "Laptop");
        when(productRepository.findById(1L)).thenReturn(Optional.of(product));

        // when
        ProductDTO result = productService.findById(1L);

        // then
        assertThat(result.getName()).isEqualTo("Laptop");
        verify(productRepository).findById(1L);
    }
}

Glowne funkcje: @Mock, @InjectMocks, when(...).thenReturn(...), verify(...), @Spy, @Captor

41. Co to jest TDD?

TDD (Test-Driven Development) - technika, gdzie najpierw piszesz test, potem kod.

42. Jak testujesz kontrolery w Spring Boot?

@WebMvcTest(ProductController.class)  // laduje tylko warstwe web
class ProductControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean  // mock dla beana w kontekscie Springa
    private ProductService productService;

    @Test
    void shouldReturnProductById() throws Exception {
        // given
        ProductDTO product = new ProductDTO(1L, "Laptop", BigDecimal.valueOf(999));
        when(productService.findById(1L)).thenReturn(product);

        // when & then
        mockMvc.perform(get("/api/products/1")
                .contentType(MediaType.APPLICATION_JSON))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.id").value(1))
            .andExpect(jsonPath("$.name").value("Laptop"));
    }
}

43. Jak znajdziesz i naprawisz memory leak?

Memory Leak (wyciek pamieci) - sytuacja, gdy aplikacja alokuje pamiec, ale nigdy jej nie zwalnia, mimo ze juz jej nie potrzebuje. W Javie oznacza to obiekty, ktore nie sa uzywane, ale Garbage Collector nie moze ich usunac, bo wciaz istnieja do nich referencje.

1. Identyfikacja:

# Monitoring heap
jstat -gc <pid> 1000

# Heap dump przy OutOfMemoryError
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof -jar app.jar

2. Typowe przyczyny:

• Niezamkniete zasoby - uzywaj try-with-resources
• Statyczne kolekcje - uzywaj bounded cache lub WeakHashMap
• Listenery nie usuwane - unregister w @PreDestroy
• ThreadLocal nie czyszczony - zawsze wywoluj remove() w finally

Przyklady kodu - JAK NIE robic vs JAK robic:

1. Statyczna kolekcja (cache bez limitu):

// ZLE - memory leak! Kolekcja rosnie w nieskonczonosc
public class UserCache {
    private static final Map<Long, User> cache = new HashMap<>();

    public void addUser(User user) {
        cache.put(user.getId(), user);  // Nigdy nie usuwane!
    }
}

// DOBRZE - ograniczony cache z LRU eviction
public class UserCache {
    private static final int MAX_SIZE = 1000;
    private static final Map<Long, User> cache = new LinkedHashMap<>(MAX_SIZE, 0.75f, true) {
        @Override
        protected boolean removeEldestEntry(Map.Entry<Long, User> eldest) {
            return size() > MAX_SIZE;  // Usuwa najstarszy gdy przekroczy limit
        }
    };
}

// JESZCZE LEPIEJ - Caffeine/Guava Cache
Cache<Long, User> cache = Caffeine.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .build();

2. Niezamkniete zasoby (InputStream, Connection):

// ZLE - memory leak! Stream nigdy nie zamkniety
public String readFile(String path) throws IOException {
    FileInputStream fis = new FileInputStream(path);
    byte[] data = fis.readAllBytes();
    return new String(data);
    // fis.close() NIGDY nie wywolane - wyciek!
}

// DOBRZE - try-with-resources (automatyczne zamkniecie)
public String readFile(String path) throws IOException {
    try (FileInputStream fis = new FileInputStream(path)) {
        byte[] data = fis.readAllBytes();
        return new String(data);
    }  // fis.close() wywolane automatycznie (nawet przy uzyciu wyjatku)
}

3. ThreadLocal bez czyszczenia:

// ZLE - memory leak w aplikacji webowej!
public class UserContext {
    private static final ThreadLocal<User> currentUser = new ThreadLocal<>();

    public static void setUser(User user) {
        currentUser.set(user);  // Watek z puli trzyma referencje na zawsze!
    }
}

// DOBRZE - zawsze czyscimy w finally lub uzyj filtra
public class UserContext {
    private static final ThreadLocal<User> currentUser = new ThreadLocal<>();

    public static void setUser(User user) { currentUser.set(user); }
    public static void clear() { currentUser.remove(); }  // KRYTYCZNE!
}

// W filtrze Spring:
@Component
public class UserContextFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        try {
            UserContext.setUser(extractUser(req));
            chain.doFilter(req, res);
        } finally {
            UserContext.clear();  // ZAWSZE czyscimy po uzyciu zadania
        }
    }
}

4. Listenery/Observery bez wyrejestrowania:

// ZLE - memory leak! Listener trzyma referencje do obiektu
@Service
public class OrderService {
    @Autowired
    private EventPublisher publisher;

    @PostConstruct
    public void init() {
        publisher.addListener(this::onEvent);  // Zarejestrowany na zawsze!
    }
}

// DOBRZE - wyrejestrowanie w @PreDestroy
@Service
public class OrderService {
    @Autowired
    private EventPublisher publisher;
    private Consumer<Event> listener;

    @PostConstruct
    public void init() {
        listener = this::onEvent;
        publisher.addListener(listener);
    }

    @PreDestroy
    public void cleanup() {
        publisher.removeListener(listener);  // Wyrejestrowanie!
    }
}

5. Klasy wewnetrzne (inner class) trzymajace referencje:

// ZLE - non-static inner class trzyma referencje do outer class
public class HeavyObject {
    private byte[] data = new byte[10_000_000];  // 10MB

    public Runnable createTask() {
        return new Runnable() {  // Anonimowa klasa trzyma ref do HeavyObject!
            public void run() { System.out.println("Task"); }
        };
    }
}

// DOBRZE - static nested class lub lambda bez referencji
public class HeavyObject {
    private byte[] data = new byte[10_000_000];

    public Runnable createTask() {
        return () -> System.out.println("Task");  // Lambda bez ref do this
    }

    // Lub static nested class:
    private static class MyTask implements Runnable {
        public void run() { System.out.println("Task"); }
    }
}

44. Jak zoptymalizujesz wolne zapytanie SQL?

W srodowiskach o duzym obciazeniu, optymalizacja wydajnosci transakcji jest niezbedna. Im krocej trwa zapytanie, tym krocej trzyma locki.

-- Analiza z EXPLAIN ANALYZE
EXPLAIN ANALYZE
SELECT * FROM orders WHERE created_at > '2024-01-01';

Typowe problemy i rozwiazania:

• Brak indeksu - CREATE INDEX na kolumnach w WHERE, JOIN, ORDER BY. Bez indeksu baza musi przeskanowac cala tabele (full table scan). Indeks dziala jak spis tresci w ksiazce - pozwala szybko znalezc dane bez przegladania wszystkiego.
• SELECT * - wybieraj tylko potrzebne kolumny. Pobieranie wszystkich kolumn zwieksza transfer danych, zuzycie pamieci i uniemozliwia uzycie covering index (indeks zawierajacy wszystkie potrzebne dane).
• Funkcje na kolumnach w WHERE - indeks nie zadziala, bo baza musi obliczyc wynik funkcji dla kazdego wiersza. Np. WHERE YEAR(created_at) = 2024 wymaga full scan. Rozwiazanie: WHERE created_at BETWEEN '2024-01-01' AND '2024-12-31' lub functional index.
• LIKE z % na poczatku - LIKE '%tekst' nie moze uzyc indeksu B-tree, bo nie zna poczatku szukanego ciagu. Rozwiazanie: Full-Text Search (np. PostgreSQL tsvector, Elasticsearch) lub trigram index (pg_trgm).
• Duzy OFFSET - OFFSET 100000 wymusza przeskanowanie i pomieniecie 100k wierszy. Im wieksza strona, tym wolniej. Rozwiazanie: keyset pagination (cursor-based) - zamiast OFFSET uzywaj WHERE id > last_seen_id ORDER BY id LIMIT 20. Zawsze stala wydajnosc niezaleznie od numeru strony.

1. Indeksowanie

Poprawia wydajnosc zapytan, ale wymaga rownowagi - zbyt wiele indeksow wydluza czas zapisu (INSERT/UPDATE).

-- Zamiast wolnego zapytania:
SELECT * FROM orders
WHERE user_id = 123
ORDER BY created_at DESC;

-- Utworz indeks kompozytowy:
CREATE INDEX idx_orders_user_created
ON orders(user_id, created_at DESC);

W JPA/Hibernate:

@Entity
@Table(
    name = "orders",
    indexes = {
        @Index(name = "idx_orders_user_created", columnList = "user_id, created_at")
    }
)
public class Order {
    // ...
}

2. Unikanie SELECT *

Pobieraj tylko potrzebne kolumny - zmniejsza transfer danych i obciazenie pamieci.

-- ZLE: pobiera wszystkie kolumny
SELECT * FROM orders WHERE user_id = 123;

-- DOBRZE: tylko potrzebne kolumny
SELECT id, status, created_at FROM orders WHERE user_id = 123;

W JPA - projekcja do DTO:

// DTO
public record OrderSummaryDto(
    Long id,
    OrderStatus status,
    LocalDateTime createdAt
) {}

// Repository - projekcja zamiast calej encji
@Query("""
    SELECT new projekt.dto.OrderSummaryDto(
        o.id,
        o.status,
        o.createdAt
    )
    FROM Order o
    WHERE o.userId = :userId
""")
List<OrderSummaryDto> findOrderSummariesByUserId(@Param("userId") Long userId);

3. Batching - unikanie N+1 / petli

Zamiast wielu pojedynczych zapytan, uzyj jednego z IN (...).

// ZLE - N zapytan (petla)
List<Long> userIds = List.of(1L, 2L, 3L);
List<Order> allOrders = new ArrayList<>();

for (Long userId : userIds) {
    allOrders.addAll(orderRepository.findByUserId(userId));
}
// Generuje N zapytan:
// SELECT * FROM orders WHERE user_id = 1;
// SELECT * FROM orders WHERE user_id = 2;
// SELECT * FROM orders WHERE user_id = 3;

// DOBRZE - jedno zapytanie z IN
List<Order> orders = orderRepository.findByUserIdIn(userIds);

// Repository:
interface OrderRepository extends JpaRepository<Order, Long> {
    List<Order> findByUserIdIn(List<Long> userIds);
}
// Generuje: SELECT * FROM orders WHERE user_id IN (1, 2, 3);

4. Przetwarzanie wsadowe (Batch Insert/Update)

Grupuje operacje zapisu w celu zmniejszenia liczby round-tripow do bazy.

// ZLE - N operacji INSERT
for (Order o : orders) {
    orderRepository.save(o);  // Kazdy save = oddzielny INSERT
}

// DOBRZE - batch insert
orderRepository.saveAll(orders);  // Jeden batch

// Konfiguracja w application.yml:
spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 50
        order_inserts: true
        order_updates: true

5. Pula polaczen (Connection Pool)

Ponowne wykorzystanie polaczen zamiast tworzenia nowych (kosztowna operacja).

# HikariCP - domyslny w Spring Boot
spring:
  datasource:
    hikari:
      maximum-pool-size: 20        # Max polaczen w puli
      minimum-idle: 5             # Min polaczen gotowych
      connection-timeout: 30000   # Timeout na pobranie polaczenia (ms)
      idle-timeout: 600000        # Czas bezczynnosci przed zamknieciem

6. Kontrola wspolbieznosci - blokowanie na poziomie wiersza

Row-level locking zamiast table-level - pozwala na rownoczesne transakcje na roznych wierszach.

-- Row-level lock (tylko wiersz id=1)
SELECT * FROM orders WHERE id = 1 FOR UPDATE;

-- NOWAIT - nie czekaj, rzuc blad jesli zablokowane
SELECT * FROM orders WHERE id = 1 FOR UPDATE NOWAIT;

-- SKIP LOCKED - pomin zablokowane wiersze (dobre dla queue)
SELECT * FROM tasks WHERE status = 'PENDING'
ORDER BY created_at LIMIT 1 FOR UPDATE SKIP LOCKED;

7. Rownowazenie obciazenia (Read Replicas)

Rozklad obciazenia przez replikacje - zapisy do mastera, odczyty z replik.

// Spring - @Transactional(readOnly = true) kieruje na replike
@Transactional(readOnly = true)
public List<Order> findAllOrders() {
    return orderRepository.findAll();  // Idzie na replike
}

@Transactional
public void createOrder(Order order) {
    orderRepository.save(order);  // Idzie na mastera
}

Podsumowanie technik optymalizacji

45. Zaprojektuj system kolejkowania zadan

Kluczowe elementy:

• Task entity - id, type, payload, status, attempts, maxAttempts, priority
• Producer - zapisuje task do DB i kolejki
• Worker - pobiera task, wykonuje, obsluguje retry z exponential backoff
• Handler interface - rozne handlery dla roznych typow taskow

46. Live coding: endpoint CRUD

// Entity
@Entity
@Data
public class Product {
    @Id @GeneratedValue
    private Long id;
    @NotBlank
    private String name;
    @NotNull @Positive
    private BigDecimal price;
}

// Controller
@RestController
@RequestMapping("/api/products")
@RequiredArgsConstructor
public class ProductController {

    private final ProductService service;

    @GetMapping
    public Page<ProductResponse> getAll(Pageable pageable) {
        return service.findAll(pageable);
    }

    @GetMapping("/{id}")
    public ProductResponse getById(@PathVariable Long id) {
        return service.findById(id);
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public ProductResponse create(@Valid @RequestBody ProductRequest request) {
        return service.create(request);
    }

    @PutMapping("/{id}")
    public ProductResponse update(@PathVariable Long id,
                                    @Valid @RequestBody ProductRequest request) {
        return service.update(id, request);
    }

    @DeleteMapping("/{id}")
    @ResponseStatus(HttpStatus.NO_CONTENT)
    public void delete(@PathVariable Long id) {
        service.delete(id);
    }
}

47. Jakie sa najwazniejsze naglowki HTTP i do czego sluza?

Naglowki HTTP to metadane przesylane miedzy klientem a serwerem. Dziela sie na kategorie:

Naglowki zadania (Request Headers):

Naglowki odpowiedzi (Response Headers):

Naglowki CORS:

Naglowki bezpieczenstwa:

48. Jak dziala cacheowanie z naglowkami HTTP?

// Spring - ustawianie naglowkow cache
@GetMapping("/products/{id}")
public ResponseEntity<Product> getProduct(@PathVariable Long id) {
    Product product = productService.findById(id);

    return ResponseEntity.ok()
        .cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS))
        .eTag(String.valueOf(product.hashCode()))
        .body(product);
}

49. Czym rozni sie autentykacja od autoryzacji?

50. Co to jest Keycloak i jakie problemy rozwiazuje?

Keycloak - open-source'owy serwer Identity and Access Management (IAM) od Red Hat.

Funkcje:

• Single Sign-On (SSO) - jeden login do wielu aplikacji
• Identity Brokering - logowanie przez Google, GitHub, Facebook
• User Federation - integracja z LDAP/Active Directory
• Standardy - OAuth 2.0, OpenID Connect, SAML 2.0
• Zarzadzanie uzytkownikami - rejestracja, resetowanie hasla, 2FA
• Role i uprawnienia - RBAC (Role-Based Access Control)

50a. Jakie sa ustawienia klienta w Keycloak (Capability Config)?

W Keycloak kazdy klient ma Capability config - ustawienia okreslajace jak klient moze sie uwierzytelniac i jakie ma uprawnienia.

Czym jest client_id i client_secret?

# Gdzie znajdziesz te wartosci w Keycloak:
# 1. Zaloguj sie do Keycloak Admin Console
# 2. Wybierz realm (np. car-shop)
# 3. Clients -> wybierz klienta

# client_id:
#   Zakladka "Settings" -> pole "Client ID"
#   Np: api-communication-client

# client_secret:
#   Zakladka "Credentials" -> pole "Client secret"
#   Np: BeY47DCttqijpIOaU9oF2QVRbR7EXzHF
#   (widoczne tylko gdy Client authentication = ON)

Client authentication (On/Off)

Authorization (On/Off)

Authentication flow - typy przeplywow

Przyklad: Dwa rozne klienty w jednym systemie

# KLIENT 1: Frontend - uzytkownik loguje sie przez przegladarke
# Ustawienia w Keycloak:
#   - Client authentication: OFF
#   - Standard flow: ON
#   - Valid redirect URIs: http://localhost:3000/*

# Frontend (React) - przekierowanie do Keycloak
const loginUrl = `
  https://keycloak.example.com/realms/car-shop/protocol/openid-connect/auth
  ?client_id=frontend-client
  &response_type=code
  &redirect_uri=http://localhost:3000/callback
  &scope=openid`;

window.location.href = loginUrl;

# KLIENT 2: Backend service - komunikacja miedzy mikroserwisami
# Ustawienia w Keycloak:
#   - Client authentication: ON
#   - Service accounts roles: ON
#   - Standard flow: OFF

# application.yml
spring:
  security:
    oauth2:
      client:
        registration:
          api-communication-client:
            client-id: api-communication-client
            client-secret: BeY47DCttqijpIOaU9oF2QVRbR7EXzHF  # z Keycloak -> Credentials
            authorization-grant-type: client_credentials
            scope: openid
        provider:
          keycloak:
            token-uri: https://keycloak.example.com/realms/car-shop/protocol/openid-connect/token

51. Jak skonfigurowac Spring Boot z Keycloak?

# application.yml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://keycloak:8080/realms/my-realm
          jwk-set-uri: http://keycloak:8080/realms/my-realm/protocol/openid-connect/certs

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .requestMatchers("/api/user/**").hasAnyRole("USER", "ADMIN")
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthConverter()))
            )
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .build();
    }

    // Konwersja rol z Keycloak do Spring Security
    @Bean
    public JwtAuthenticationConverter jwtAuthConverter() {
        JwtGrantedAuthoritiesConverter converter = new JwtGrantedAuthoritiesConverter();
        converter.setAuthoritiesClaimName("realm_access.roles");
        converter.setAuthorityPrefix("ROLE_");

        JwtAuthenticationConverter jwtConverter = new JwtAuthenticationConverter();
        jwtConverter.setJwtGrantedAuthoritiesConverter(converter);
        return jwtConverter;
    }
}

52. Jak wyglada struktura tokena JWT z Keycloak?

// JWT sklada sie z 3 czesci: HEADER.PAYLOAD.SIGNATURE

// HEADER (algorytm i typ)
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-123"
}

// PAYLOAD (claims - dane)
{
  "exp": 1699999999,           // expiration time
  "iat": 1699996399,           // issued at
  "iss": "http://keycloak:8080/realms/my-realm",  // issuer
  "sub": "user-uuid-123",     // subject (user ID)
  "aud": "my-client",          // audience
  "typ": "Bearer",
  "azp": "my-client",          // authorized party
  "preferred_username": "jan.kowalski",
  "email": "jan@example.com",
  "realm_access": {
    "roles": ["USER", "ADMIN"]
  },
  "resource_access": {
    "my-client": {
      "roles": ["view-products", "edit-products"]
    }
  }
}

// SIGNATURE - weryfikuje integralnosc tokena
// RSASHA256(base64(header) + "." + base64(payload), privateKey)

53. Czym rozni sie Access Token od Refresh Token?

// Odswiezanie tokena
POST /realms/my-realm/protocol/openid-connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=eyJhbGciOiJIUzI1NiIs...
&client_id=my-client
&client_secret=secret123

54. Czym rozni sie haszowanie od szyfrowania i kodowania?

55. Jakie algorytmy haszowania nalezy znac?

Do hasel (wolne, z sola):

Do integralnosci danych (szybkie):

// Spring Security - haszowanie hasla z bcrypt
@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(12); // cost factor 12
}

// Uzycie
String hash = passwordEncoder.encode("password123");
// $2a$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/X4.mfIgPLGCOqK6Fi

boolean matches = passwordEncoder.matches("password123", hash); // true

Co znaczy "odporny na GPU"?
Algorytm jest zaprojektowany tak, aby wymagac duzej ilosci pamieci RAM (memory-hard). Karty GPU maja ogromna moc obliczeniowa, ale ograniczona pamiec na pojedynczy watek, przez co nie moga efektywnie wykonywac milionow prob haszowania rownolegle.

Ataki na hasla – co warto znac?

1. Rainbow Table Attack

Atak polega na wykorzystaniu gotowych tabel zawierajacych pary: hash → oryginalne haslo. Atakujacy nie musi liczyc hasha – tylko sprawdza go w ogromnej bazie.

Dlaczego to dziala?

• Te samo haslo zawsze daje ten sam hash (bez soli)
• Popularne hasla sa juz wczesniej wyliczone

Jak sie bronic?

• Uzywac salt – kazde haslo ma inny hash
• Stosowac wolne algorytmy: Argon2, bcrypt, scrypt

2. Brute Force Attack

Atak polega na sprawdzaniu kazdej mozliwej kombinacji znakow az do znalezienia poprawnego hasla.

Cechy:

• Nie wymaga slownika
• Bardzo kosztowny obliczeniowo
• GPU znacząco go przyspiesza

Obrona:

• Memory-hard hashing (Argon2)
• Dlugie hasla
• MFA / 2FA

3. Dictionary Attack

Atakujacy testuje liste najpopularniejszych hasel oraz slow ze slownika. Jest znacznie szybszy niz brute force.

Przyklady hasel latwych do zlamania:

• password123
• qwerty
• admin

Obrona:

• Wymuszanie silnych hasel
• Blokady po wielu probach logowania

4. Credential Stuffing

Wykorzystuje dane wyciekle z innych serwisow. Atakujacy automatycznie probuje kombinacji email + haslo na wielu stronach.

Dlaczego jest skuteczny?

• Uzytkownicy ponownie wykorzystuja te same hasla

Obrona:

• MFA
• Sprawdzanie hasel z baz wyciekow (np. HaveIBeenPwned)

5. Password Spraying

Zamiast probowac wielu hasel dla jednego konta, atakujacy probuje jednego popularnego hasla dla wielu kont.

Cel: ominiecie blokad konta.

Obrona:

• Polityka silnych hasel
• Wykrywanie anomalii logowania

6. GPU / Hardware Attack

Wykorzystuje karty graficzne lub specjalizowany sprzet (ASIC), aby liczyc miliony hashy na sekunde.

Obrona:

• Algorytmy memory-hard (Argon2, scrypt)
• Wysoki cost factor

7. Phishing

Atak socjotechniczny – uzytkownik sam podaje haslo na falszywej stronie przypominajacej prawdziwy serwis.

Obrona:

• 2FA
• Klucze sprzetowe (FIDO2)
• Szkolenia security awareness

Najwazniejsza zasada bezpieczenstwa

Co warto powiedziec na rozmowie?

• Najwiekszym zagrozeniem sa ataki offline po wycieku bazy.
• Dlatego stosujemy memory-hard hashing.
• Sam hash to za malo — potrzebne sa tez MFA i rate limiting.

56. Co to jest sol (salt) i pieprz (pepper) w haszowaniu?

56b. Wyciek bazy danych i jak się przed nim chronić

Wyciek bazy danych (data breach) to sytuacja, w której nieuprawniona osoba uzyskuje dostęp do danych przechowywanych w systemie, np. użytkowników, haseł, tokenów, numerów kart czy danych osobowych.

Najważniejsze: Zakłada się, że wyciek kiedyś nastąpi. Dlatego system projektuje się tak, aby skradzione dane były bezużyteczne.

Jak dochodzi do wycieku?

1. SQL Injection

Atakujący wstrzykuje zapytanie SQL przez formularz lub API.

// Złe (SQL injection możliwy)
SELECT * FROM users WHERE email = '" + email + "' AND password = '" + password + "';

// Dobre (parametryzowane zapytania)
userRepository.findByEmail(email);

✅ ORM i parametryzowane zapytania eliminują SQL Injection.

2. Skradzione dane dostępowe

• Hasło do DB w repozytorium Git
• Wyciek plików .env
• Słabe hasła produkcyjne
• Brak rotacji sekretów

Obrona: Vault / AWS Secret Manager / GCP Secret Manager, rotacja kluczy, zasada least privilege.

3. Błędna konfiguracja chmury

• Publiczny bucket S3
• Otwarty port 5432 do PostgreSQL
• Brak firewalli

✅ DB powinna być dostępna tylko z prywatnej sieci (VPC).

4. Exploit podatności

• Stary Spring Boot
• Podatny Log4j (Log4Shell)
• Nieaktualny PostgreSQL
• CVE w bibliotece

✅ Regularne aktualizacje, skanery zależności (Snyk, Dependabot).

5. Malware / przejęcie serwera

• Brak patchy
• Słabe SSH / brak MFA
• Root login możliwy

Co jeśli baza wycieknie?

Najważniejsze pytanie: Czy atakujący może użyć tych danych?

• Hasła w plaintext → katastrofa
• Hasła zahashowane Argon2 → nadal bezpieczne

Jak REALNIE zabezpiecza się backend?

1. Hashowanie haseł

Absolutny MUST: Argon2 + salt + wysoki cost.

2. Szyfrowanie danych wrażliwych

PESEL, numer karty, adres → użycie encryption at rest, np. AES-256.

3. Zasada minimalnych uprawnień

Aplikacja nie powinna mieć uprawnień: SUPERUSER, DROP TABLE, ALTER DATABASE, tylko SELECT/INSERT/UPDATE.

4. Segmentacja sieci

Internet
   ↓
Load Balancer
   ↓
Backend
   ↓
Private Network
   ↓
Database

✅ Baza nigdy nie powinna być publiczna.

5. Backupy + plan incydentu

• Test restore
• Runbook incydentu
• Monitoring

6. Monitoring i alerty

• Nagły dump bazy
• Milion zapytań w krótkim czasie
• Logowanie z dziwnego IP

Stack: Prometheus, Grafana, SIEM

Ataki offline

Największe ryzyko: ktoś kradnie bazę i łamie hasła lokalnie. ✅ Dlatego szybkie hashe (SHA256) są złe, wolne (Argon2) są dobre.

Podsumowanie do rozmowy kwalifikacyjnej:

System projektuję tak, jakby wyciek bazy był nieunikniony. Hasła haszuję Argon2 z salt, dane wrażliwe szyfruję, stosuję least privilege i izoluję bazę w prywatnej sieci. Dzięki temu nawet w przypadku breach attacker nie może łatwo wykorzystać danych.

57. Jakie sa rodzaje szyfrowania?

Szyfrowanie symetryczne (ten sam klucz):

Szyfrowanie asymetryczne (klucz publiczny + prywatny):

58. Czym sa zasady SOLID?

SOLID - 5 zasad projektowania obiektowego, ktore prowadza do czytelnego, elastycznego i latwo testowalnego kodu.

59. Single Responsibility Principle (SRP) - przyklad

Zasada: Klasa powinna mieć tylko jedną odpowiedzialność i tylko jeden powód do zmiany. Pojedyncza klasa nie powinna pełnić wielu ról jednocześnie, ponieważ wtedy staje się trudna w utrzymaniu, testowaniu i rozwoju.

// ZLE - klasa ma wiele odpowiedzialnosci
public class UserService {
    public void createUser(User user) { /* ... */ }
    public void sendWelcomeEmail(User user) { /* ... */ }
    public String generateReport(List<User> users) { /* ... */ }
    public void exportToPdf(String report) { /* ... */ }
}

// DOBRZE - kazda klasa ma jedna odpowiedzialnosc
public class UserService {
    public void createUser(User user) { /* ... */ }
}

public class EmailService {
    public void sendWelcomeEmail(User user) { /* ... */ }
}

public class UserReportGenerator {
    public String generateReport(List<User> users) { /* ... */ }
}

public class PdfExporter {
    public void export(String content) { /* ... */ }
}

60. Open/Closed Principle (OCP) - przyklad

Zasada: Oprogramowanie (klasy, moduły) powinno być otwarte na rozszerzenia, ale zamknięte na modyfikacje. Nową funkcjonalność dodajemy poprzez rozszerzenie (np. przez dziedziczenie lub wzorce projektowe), a nie przez bezpośrednią modyfikację istniejących klas.

// ZLE - trzeba modyfikowac klase przy kazdym nowym typie
public class DiscountCalculator {
    public BigDecimal calculate(Order order) {
        if (order.getCustomerType() == CustomerType.REGULAR) {
            return order.getTotal().multiply(new BigDecimal("0.05"));
        } else if (order.getCustomerType() == CustomerType.VIP) {
            return order.getTotal().multiply(new BigDecimal("0.15"));
        }
        // Dodanie nowego typu wymaga modyfikacji tej klasy!
        return BigDecimal.ZERO;
    }
}

// DOBRZE - rozszerzamy przez nowe implementacje
public interface DiscountStrategy {
    BigDecimal calculate(Order order);
}

public class RegularDiscount implements DiscountStrategy {
    public BigDecimal calculate(Order order) {
        return order.getTotal().multiply(new BigDecimal("0.05"));
    }
}

public class VipDiscount implements DiscountStrategy {
    public BigDecimal calculate(Order order) {
        return order.getTotal().multiply(new BigDecimal("0.15"));
    }
}

// Dodanie nowego typu = nowa klasa, BEZ modyfikacji istniejacych
public class BlackFridayDiscount implements DiscountStrategy {
    public BigDecimal calculate(Order order) {
        return order.getTotal().multiply(new BigDecimal("0.30"));
    }
}

61. Liskov Substitution Principle (LSP) - przyklad

Zasada: Obiekty klasy bazowej powinny być wymienialne z obiektami klasy pochodnej bez wpływu na poprawność działania programu. Podklasa nie powinna łamać zachowania oczekiwanego od klasy bazowej.

// ZLE - lamie LSP (kwadrat nie jest prostokatem w sensie zachowania)
public class Rectangle {
    protected int width, height;

    public void setWidth(int w) { width = w; }
    public void setHeight(int h) { height = h; }
    public int getArea() { return width * height; }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int w) { width = height = w; }
    @Override
    public void setHeight(int h) { width = height = h; }
}

// Problem:
Rectangle rect = new Square();
rect.setWidth(5);
rect.setHeight(10);
rect.getArea(); // Oczekujemy 50, dostajemy 100! Zlamana zasada.

// DOBRZE - oddzielne klasy lub wspolny interfejs
public interface Shape {
    int getArea();
}

public class Rectangle implements Shape {
    private final int width, height;
    public Rectangle(int w, int h) { width = w; height = h; }
    public int getArea() { return width * height; }
}

public class Square implements Shape {
    private final int side;
    public Square(int s) { side = s; }
    public int getArea() { return side * side; }
}

62. Interface Segregation Principle (ISP) - przyklad

Zasada: Zamiast jednego dużego interfejsu powinno się definiować wiele mniejszych, specyficznych interfejsów, tak aby klasy implementowały tylko te metody, które są dla nich rzeczywiście potrzebne. Dzięki temu kod staje się bardziej modularny i łatwiejszy do testowania.

// ZLE - jeden duzy interfejs
public interface Worker {
    void work();
    void eat();
    void sleep();
    void code();
    void attendMeeting();
}

// Robot nie je ani nie spi - musi implementowac puste metody
public class Robot implements Worker {
    public void work() { /* ok */ }
    public void eat() { /* nie dotyczy! */ }
    public void sleep() { /* nie dotyczy! */ }
    public void code() { /* ok */ }
    public void attendMeeting() { /* nie dotyczy! */ }
}

// DOBRZE - wiele malych interfejsow
public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public interface Sleepable {
    void sleep();
}

public interface Programmer extends Workable {
    void code();
}

// Robot implementuje tylko to co potrzebuje
public class Robot implements Workable, Programmer {
    public void work() { /* ... */ }
    public void code() { /* ... */ }
}

// Czlowiek implementuje wiecej
public class Human implements Workable, Eatable, Sleepable, Programmer {
    /* wszystkie metody */
}

63. Dependency Inversion Principle (DIP) - przyklad

Zasada: Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Oba powinny zależeć od abstrakcji (np. interfejsów), a nie od konkretnych implementacji. Prowadzi to do słabego sprzężenia i większej elastyczności kodu.

// ZLE - bezposrednia zaleznosc od konkretnej implementacji
public class OrderService {
    private MySqlOrderRepository repository = new MySqlOrderRepository();
    private SmtpEmailSender emailSender = new SmtpEmailSender();

    public void createOrder(Order order) {
        repository.save(order);
        emailSender.send(order.getCustomerEmail(), "Order created");
    }
}
// Nie mozna latwo zmienic bazy ani sposobu wysylania maili
// Nie mozna testowac bez prawdziwej bazy i serwera SMTP

// DOBRZE - zaleznosc od abstrakcji (interfejsow)
public interface OrderRepository {
    void save(Order order);
}

public interface NotificationService {
    void notify(String recipient, String message);
}

@Service
public class OrderService {
    private final OrderRepository repository;
    private final NotificationService notificationService;

    // Dependency Injection przez konstruktor
    public OrderService(OrderRepository repository,
                        NotificationService notificationService) {
        this.repository = repository;
        this.notificationService = notificationService;
    }

    public void createOrder(Order order) {
        repository.save(order);
        notificationService.notify(order.getCustomerEmail(), "Order created");
    }
}

// Mozna latwo podmienic implementacje:
// - MySqlOrderRepository, MongoOrderRepository, InMemoryOrderRepository
// - SmtpEmailSender, SmsNotification, MockNotification (w testach)

64. Co to jest Model Dojrzalosci Richardsona?

Richardson Maturity Model - model opisujacy poziomy dojrzalosci API RESTowego. Stworzony przez Leonarda Richardsona.

65. Poziom 0 - The Swamp of POX

Jedno URL jako tunel dla wszystkich operacji. Praktycznie RPC over HTTP.

// Wszystko przez jeden endpoint
POST /api/service HTTP/1.1
Content-Type: application/json

{
  "action": "getUser",
  "userId": 123
}

POST /api/service HTTP/1.1
{
  "action": "createOrder",
  "customerId": 456,
  "products": [...]
}

POST /api/service HTTP/1.1
{
  "action": "deleteUser",
  "userId": 123
}

66. Poziom 1 - Resources

Rozne URLe dla roznych zasobow, ale nadal jedna metoda (zazwyczaj POST).

// Osobne endpointy dla zasobow
POST /users/get
{
  "userId": 123
}

POST /users/create
{
  "name": "Jan",
  "email": "jan@example.com"
}

POST /orders/create
{
  "customerId": 456,
  "products": [...]
}

67. Poziom 2 - HTTP Verbs

Poprawne uzycie metod HTTP i kodow statusu. To jest standard dla wiekszosc API REST.

// Pobieranie
GET /users/123
// Response: 200 OK + dane uzytkownika

// Tworzenie
POST /users
{ "name": "Jan", "email": "jan@example.com" }
// Response: 201 Created + Location: /users/123

// Aktualizacja
PUT /users/123
{ "name": "Jan Nowak", "email": "jan@example.com" }
// Response: 200 OK

// Usuniecie
DELETE /users/123
// Response: 204 No Content

// Bledy
GET /users/999
// Response: 404 Not Found

POST /users
{ "email": "invalid" }
// Response: 400 Bad Request

68. Poziom 3 - HATEOAS (Hypermedia)

HATEOAS (Hypermedia as the Engine of Application State) - odpowiedzi zawieraja linki do mozliwych akcji.

GET /orders/123

{
  "id": 123,
  "status": "PENDING",
  "total": 299.99,
  "customer": {
    "id": 456,
    "name": "Jan Kowalski"
  },
  "_links": {
    "self": {
      "href": "/orders/123"
    },
    "customer": {
      "href": "/customers/456"
    },
    "cancel": {
      "href": "/orders/123/cancel",
      "method": "POST"
    },
    "pay": {
      "href": "/orders/123/payment",
      "method": "POST"
    },
    "items": {
      "href": "/orders/123/items"
    }
  }
}

// Po oplaceniu zamowienia - inne dostepne akcje
GET /orders/123

{
  "id": 123,
  "status": "PAID",
  "_links": {
    "self": { "href": "/orders/123" },
    "ship": { "href": "/orders/123/ship", "method": "POST" },
    "refund": { "href": "/orders/123/refund", "method": "POST" }
    // "cancel" i "pay" juz niedostepne!
  }
}

// Spring HATEOAS
@GetMapping("/orders/{id}")
public EntityModel<Order> getOrder(@PathVariable Long id) {
    Order order = orderService.findById(id);

    EntityModel<Order> model = EntityModel.of(order);

    model.add(linkTo(methodOn(OrderController.class).getOrder(id)).withSelfRel());
    model.add(linkTo(methodOn(CustomerController.class).getCustomer(order.getCustomerId())).withRel("customer"));

    if (order.getStatus() == Status.PENDING) {
        model.add(linkTo(methodOn(OrderController.class).cancelOrder(id)).withRel("cancel"));
        model.add(linkTo(methodOn(PaymentController.class).pay(id)).withRel("pay"));
    }

    return model;
}

69. Jakie sa 4 filary programowania obiektowego?

70. Co to jest enkapsulacja i dlaczego jest wazna?

Enkapsulacja - ukrywanie wewnetrznego stanu obiektu i udostepnianie kontrolowanego dostepu przez metody.

// ZLE - publiczne pola, brak kontroli
public class BankAccount {
    public BigDecimal balance;  // kazdy moze zmienic!
}

BankAccount account = new BankAccount();
account.balance = new BigDecimal("-1000"); // ujemne saldo?!

// DOBRZE - prywatne pola, kontrola przez metody
public class BankAccount {
    private BigDecimal balance;

    public BankAccount(BigDecimal initialBalance) {
        if (initialBalance.compareTo(BigDecimal.ZERO) < 0) {
            throw new IllegalArgumentException("Initial balance cannot be negative");
        }
        this.balance = initialBalance;
    }

    public BigDecimal getBalance() {
        return balance;  // tylko odczyt
    }

    public void deposit(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
        balance = balance.add(amount);
    }

    public void withdraw(BigDecimal amount) {
        if (amount.compareTo(balance) > 0) {
            throw new InsufficientFundsException("Not enough balance");
        }
        balance = balance.subtract(amount);
    }
}

71. Co to jest abstrakcja?

Abstrakcja - pokazywanie tylko istotnych cech, ukrywanie szczegulow implementacji.

// Abstrakcja - definiuje CO ma byc zrobione, nie JAK
public interface PaymentProcessor {
    PaymentResult processPayment(PaymentRequest request);
}

// Uzytkownik nie musi znac szczegulow implementacji
public class OrderService {
    private final PaymentProcessor paymentProcessor;

    public void checkout(Order order) {
        // Nie wiem czy to Stripe, PayPal czy przelew - i nie musza wiedziec!
        PaymentResult result = paymentProcessor.processPayment(
            new PaymentRequest(order.getTotal())
        );
    }
}

// Rozne implementacje - ukryte szczegoly
public class StripePaymentProcessor implements PaymentProcessor {
    public PaymentResult processPayment(PaymentRequest request) {
        // Cala logika Stripe API tutaj
    }
}

public class PayPalPaymentProcessor implements PaymentProcessor {
    public PaymentResult processPayment(PaymentRequest request) {
        // Cala logika PayPal API tutaj
    }
}

72. Co to jest dziedziczenie i kiedy je stosowac?

Dziedziczenie - mechanizm pozwalajacy klasie przejac pola i metody innej klasy.

// Klasa bazowa
public abstract class Vehicle {
    protected String brand;
    protected int year;

    public void start() {
        System.out.println("Vehicle starting...");
    }

    public abstract void move();  // musi byc zaimplementowana
}

// Klasy pochodne
public class Car extends Vehicle {
    private int numberOfDoors;

    @Override
    public void move() {
        System.out.println("Car driving on road");
    }
}

public class Boat extends Vehicle {
    @Override
    public void move() {
        System.out.println("Boat sailing on water");
    }
}

73. Co to jest polimorfizm?

Polimorfizm - mozliwosc traktowania obiektow roznych klas przez wspolny interfejs.

// Polimorfizm - rozne zachowanie, jeden interfejs
public interface NotificationSender {
    void send(String recipient, String message);
}

public class EmailSender implements NotificationSender {
    public void send(String recipient, String message) {
        System.out.println("Sending EMAIL to " + recipient);
    }
}

public class SmsSender implements NotificationSender {
    public void send(String recipient, String message) {
        System.out.println("Sending SMS to " + recipient);
    }
}

public class PushSender implements NotificationSender {
    public void send(String recipient, String message) {
        System.out.println("Sending PUSH to " + recipient);
    }
}

// Polimorficzne uzycie - kod nie zalezy od konkretnej implementacji
public class NotificationService {
    private final List<NotificationSender> senders;

    public void notifyAll(String recipient, String message) {
        for (NotificationSender sender : senders) {
            sender.send(recipient, message);  // rozne zachowanie!
        }
    }
}

// Typy polimorfizmu:
// 1. Compile-time (przeciazanie metod - overloading)
public void print(String s) { }
public void print(int i) { }
public void print(String s, int count) { }

// 2. Runtime (nadpisywanie metod - overriding)
NotificationSender sender = new EmailSender();  // lub SmsSender
sender.send("user@email.com", "Hello");  // wywolanie zalezne od typu obiektu

74. Czym rozni sie kompozycja od dziedziczenia?

// DZIEDZICZENIE - Car IS A Vehicle
public class Car extends Vehicle {
    // dziedziczy wszystko z Vehicle
}

// KOMPOZYCJA - Car HAS AN Engine (preferowane!)
public class Car {
    private final Engine engine;        // HAS-A
    private final Transmission transmission;
    private final List<Wheel> wheels;

    public Car(Engine engine, Transmission transmission) {
        this.engine = engine;
        this.transmission = transmission;
    }

    public void start() {
        engine.start();  // delegacja do komponentu
    }
}

// Zalety kompozycji:
// - Mozna latwo podmienic Engine (ElectricEngine, DieselEngine)
// - Latwiejsze testowanie (mock Engine)
// - Brak problemow z hierarchia klas

75. Co to jest klasa, obiekt i instancja?

// Klasa - szablon
public class User {
    private String name;
    private String email;

    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }
}

// Obiekty/Instancje - konkretne egzemplarze
User user1 = new User("Jan", "jan@email.com");   // pierwsza instancja
User user2 = new User("Anna", "anna@email.com"); // druga instancja

// Kazdy obiekt ma wlasny stan (dane) ale wspoldzieli zachowanie (metody)

76. Czym roznia sie metody i pola statyczne od instancyjnych?

public class Counter {
    // Pole statyczne - wspolne dla wszystkich instancji
    private static int totalCount = 0;

    // Pole instancyjne - osobne dla kazdego obiektu
    private int instanceCount = 0;

    public Counter() {
        totalCount++;      // wspolny licznik
        instanceCount++;   // licznik tej instancji
    }

    // Metoda statyczna - dostep bez tworzenia obiektu
    public static int getTotalCount() {
        return totalCount;
    }

    // Metoda instancyjna - wymaga obiektu
    public int getInstanceCount() {
        return instanceCount;
    }
}

// Uzycie
Counter c1 = new Counter();
Counter c2 = new Counter();

Counter.getTotalCount();  // 2 (statyczna - bez obiektu)
c1.getInstanceCount();   // 1 (instancyjna - z obiektem)

77. Co to jest Deadlock?

Deadlock (zakleszczenie) - sytuacja, w ktorej dwa lub wiecej watkow/procesow czeka na siebie nawzajem, blokujac sie wzajemnie na zawsze.

4 warunki Coffmana (wszystkie musza byc spelnione):

1. Mutual Exclusion - zasob moze byc uzywany tylko przez jeden watek
2. Hold and Wait - watek trzyma zasob i czeka na kolejny
3. No Preemption - zasobu nie mozna odebrac sila
4. Circular Wait - cykliczne czekanie (A→B→C→A)

Deadlock w Java (przyklad):

public class DeadlockExample {
    private final Object lockA = new Object();
    private final Object lockB = new Object();

    public void method1() {
        synchronized(lockA) {           // 1. Zablokuj A
            synchronized(lockB) {       // 2. Czekaj na B
                // praca
            }
        }
    }

    public void method2() {
        synchronized(lockB) {           // 1. Zablokuj B
            synchronized(lockA) {       // 2. Czekaj na A  DEADLOCK!
                // praca
            }
        }
    }
}

Rozwiazanie - ustalona kolejnosc blokad:

// ZAWSZE blokuj w tej samej kolejnosci: A przed B
public void method1() {
    synchronized(lockA) {
        synchronized(lockB) { /* praca */ }
    }
}

public void method2() {
    synchronized(lockA) {           // Zmieniona kolejnosc!
        synchronized(lockB) { /* praca */ }
    }
}

78. Deadlock w bazach danych

Bazy danych automatycznie wykrywaja deadlocki i przerywaja jedna z transakcji.

-- Jak zapobiegac deadlockom w SQL:
-- 1. Ustalona kolejnosc dostępu do tabel (np. alfabetyczna)
-- 2. Krotkie transakcje (mniej czasu na konflikt)
-- 3. Niski poziom izolacji jesli mozliwe
-- 4. SELECT ... FOR UPDATE NOWAIT (nie czekaj, rzuc blad)

SELECT * FROM users WHERE id = 1 FOR UPDATE NOWAIT;
-- Jesli zablokowane, natychmiast rzuci wyjatek zamiast czekac

Strategie radzenia sobie z deadlockami:

1. Zapobieganie (Prevention) - projektuj system tak, aby unikac deadlockow:

// Java/JPA - ustalona kolejnosc zasobow
// ZAWSZE najpierw blokuj Account, potem Order (np. alfabetycznie)
@Transactional
public void transferMoney(Long accId, Long orderId) {
    // 1. Najpierw Account
    Account acc = em.find(Account.class, accId, LockModeType.PESSIMISTIC_WRITE);
    // 2. Potem Order
    Order ord = em.find(Order.class, orderId, LockModeType.PESSIMISTIC_WRITE);
    // ... operacje
}

// Timeout na poziomie JPA
@QueryHints({
    @QueryHint(name = "javax.persistence.lock.timeout", value = "5000")  // 5 sekund
})
Account findByIdWithLock(Long id);

2. Wykrywanie i rozwiazywanie (Detection & Resolution) - pozwol na deadlocki, ale wykrywaj i rozwiazuj:

• Wykresy oczekiwania (Wait-for Graph) - cykl w grafie = deadlock
• Algorytmy wykrywania - baza okresowo sprawdza cykle
• Cofanie transakcji (Victim Selection) - baza wybiera "ofiare" i wykonuje ROLLBACK

Diagnostyka locków w PostgreSQL (terminal):

# 1. Połączenie z bazą danych przez terminal
psql -h localhost -p 5434 -U product_user -d product

# Parametry połączenia:
#   -h localhost    = host bazy danych
#   -p 5434         = port (domyślny PostgreSQL to 5432)
#   -U product_user = nazwa użytkownika
#   -d product      = nazwa bazy danych

# Po połączeniu możesz wykonywać zapytania SQL:

-- 2. Wszystkie aktywne locki w systemie
SELECT * FROM pg_locks;

-- 3. Sprawdzenie które procesy są zablokowane i przez kogo
SELECT
    pid,
    usename,
    pg_blocking_pids(pid) AS blocked_by,
    query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

-- 4. Szczegółowe informacje o lockach z zapytaniami
SELECT
    l.locktype,
    l.relation::regclass,
    l.mode,
    l.granted,
    a.usename,
    a.query
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE l.relation IS NOT NULL;

-- 5. Ustawienie timeout na poziomie sesji (zapobieganie długim oczekiwaniom)
SET lock_timeout = '5s';
SET statement_timeout = '30s';

-- 6. Zabicie zablokowanego procesu (ostrożnie!)
SELECT pg_terminate_backend(pid);  -- gdzie pid = ID procesu do zabicia

3. Obsluga deadlocka w kodzie Java:

@Service
public class OrderService {

    private static final int MAX_RETRIES = 3;

    @Transactional
    public void processOrder(Long orderId) {
        int attempt = 0;
        while (attempt < MAX_RETRIES) {
            try {
                doProcessOrder(orderId);
                return;  // Sukces - wyjdz z petli
            } catch (PessimisticLockingFailureException | CannotAcquireLockException e) {
                attempt++;
                log.warn("Deadlock detected, retry {}/{}", attempt, MAX_RETRIES);
                if (attempt >= MAX_RETRIES) {
                    throw new BusinessException("Failed after " + MAX_RETRIES + " retries");
                }
                // Losowe opoznienie przed ponowna proba (unikniecie livelock)
                Thread.sleep((long) (Math.random() * 100));
            }
        }
    }
}

79. Livelock vs Starvation vs Race Condition

Race Condition - przyklad:

// PROBLEM: Race condition
private int counter = 0;

public void increment() {
    counter++;  // NIE jest atomowe! (read → modify → write)
}

// ROZWIAZANIE 1: synchronized
public synchronized void increment() {
    counter++;
}

// ROZWIAZANIE 2: AtomicInteger (lepsze)
private AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();  // Atomowa operacja
}

Livelock - przyklad:

// Dwoch "uprzejmych" watkow - obaj ustepuja i nikt nie przechodzi
while (otherThreadWantsResource) {
    releaseResource();           // "Prosze, idz pierwszy"
    Thread.sleep(100);
    acquireResource();           // "Dobra, teraz ja... o, znowu chcesz?"
}
// Oba watki ciagle zwalniaja i pobieraja - zadnego postepu

// ROZWIAZANIE: Losowe opoznienie (jak w Ethernet CSMA/CD)
Thread.sleep(new Random().nextInt(100));

80. Jak zapobiegac problemom wspolbieznosci?

ReentrantLock z timeout (zapobiega deadlock):

private final ReentrantLock lock = new ReentrantLock();

public void safeMethod() {
    try {
        // Probuj zdobyc blokade przez max 1 sekunde
        if (lock.tryLock(1, TimeUnit.SECONDS)) {
            try {
                // sekcja krytyczna
            } finally {
                lock.unlock();
            }
        } else {
            // Nie udalo sie zdobyc blokady - obsluz inaczej
            log.warn("Could not acquire lock, skipping operation");
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}

81. Optimistic vs Pessimistic Locking

Optimistic i Pessimistic Locking to strategie zarzadzania wspolbieznym dostepem do danych w transakcjach.

Optimistic Locking

Pozwala na wykonywanie transakcji bez ograniczen, sprawdzajac konflikty dopiero przed zatwierdzeniem. W przypadku wykrycia konfliktu transakcja jest wycofywana.

Java (JPA @Version):

@Entity
public class Counter {
    @Id
    private Long id;

    private int value;

    @Version  // Automatycznie inkrementowane przy UPDATE
    private Long version;
}

// Uzycie w serwisie
@Transactional
public void incrementCounter(Long id) {
    Counter counter = counterRepository.findById(id).orElseThrow();
    counter.setValue(counter.getValue() + 1);
    counterRepository.save(counter);  // Hibernate sprawdzi version przy COMMIT
}

// Obsluga konfliktu
try {
    incrementCounter(1L);
} catch (OptimisticLockException e) {
    // Konflikt! Ktos inny zmodyfikowal rekord - ponow probe lub poinformuj uzytkownika
    log.warn("Optimistic lock conflict, retrying...");
}

SQL (co generuje Hibernate):

-- Odczyt rekordu (bez blokady)
SELECT id, value, version FROM counter WHERE id = 1;
-- Wynik: id=1, value=10, version=5

-- UPDATE z warunkiem na version
UPDATE counter
SET value = 11, version = 6
WHERE id = 1 AND version = 5;

-- Jesli affected_rows = 0 → ktos inny zmienil rekord → OptimisticLockException
-- Jesli affected_rows = 1 → sukces

Pessimistic Locking

Blokuje zasoby potrzebne transakcji od razu przy odczycie, uniemozliwiajac innym dostep do nich do czasu zwolnienia blokady. Zapobiega to konfliktom, ale moze zmniejszyc wspolbieznosc i prowadzic do deadlockow.

SQL (SELECT FOR UPDATE):

-- Blokada wiersza - inne transakcje czekaja
SELECT * FROM counter WHERE id = 1 FOR UPDATE;

-- Warianty:
SELECT ... FOR UPDATE NOWAIT;       -- Nie czekaj, rzuc blad jesli zablokowane
SELECT ... FOR UPDATE SKIP LOCKED; -- Pomin zablokowane wiersze

-- Po SELECT FOR UPDATE mozna bezpiecznie UPDATE
UPDATE counter SET value = value + 1 WHERE id = 1;
COMMIT;  -- Blokada zwolniona

Java (EntityManager):

// Sposob 1: EntityManager.find() z LockModeType
@Transactional
public void incrementCounterPessimistic(Long id) {
    Counter counter = entityManager.find(
        Counter.class,
        id,
        LockModeType.PESSIMISTIC_WRITE  // SELECT ... FOR UPDATE
    );
    counter.setValue(counter.getValue() + 1);
    // Blokada trzymana do COMMIT
}

// Sposob 2: Repository z @Lock
public interface CounterRepository extends JpaRepository<Counter, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT c FROM Counter c WHERE c.id = :id")
    Counter findByIdWithLock(@Param("id") Long id);
}

// Sposob 3: Z timeout (unikniecie nieskonczonego czekania)
Map<String, Object> hints = new HashMap<>();
hints.put("javax.persistence.lock.timeout", 5000);  // 5 sekund

Counter counter = entityManager.find(
    Counter.class, id,
    LockModeType.PESSIMISTIC_WRITE,
    hints
);

LockModeType w JPA:

82. Agregacja i Kompozycja (OOP)

Agregacja i Kompozycja to relacje "has-a" w programowaniu obiektowym, różniące się siłą powiązania.

// AGREGACJA - Student istnieje niezależnie od Uniwersytetu
public class University {
    private List<Student> students;  // studenci mogą istnieć bez uniwersytetu

    public void addStudent(Student student) {
        students.add(student);  // student stworzony na zewnątrz
    }
}

// KOMPOZYCJA - Silnik nie istnieje bez Samochodu
public class Car {
    private final Engine engine;

    public Car() {
        this.engine = new Engine();  // silnik tworzony wewnątrz, umiera z samochodem
    }
}

Agregacja danych w mikroserwisach:

Łączenie danych z wielu serwisów w jedną odpowiedź.

// API Gateway agreguje dane z wielu serwisów
@GetMapping("/dashboard/{userId}")
public DashboardResponse getDashboard(@PathVariable Long userId) {
    User user = userService.getUser(userId);
    List<Order> orders = orderService.getOrders(userId);
    PaymentSummary payments = paymentService.getSummary(userId);

    return new DashboardResponse(user, orders, payments);  // agregacja
}

83. Propagacja (kontekstu, błędów, transakcji)

Propagacja oznacza przekazywanie informacji między warstwami lub komponentami systemu.

// Propagacja błędów - wyjątek domenowy → HTTP response
@Service
public class OrderService {
    public void createOrder(Order order) {
        if (order.getTotal().compareTo(BigDecimal.ZERO) <= 0) {
            throw new InvalidOrderException("Total must be positive");
        }
    }
}

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(InvalidOrderException.class)
    public ResponseEntity<ErrorResponse> handleInvalidOrder(InvalidOrderException e) {
        return ResponseEntity.badRequest().body(new ErrorResponse(e.getMessage()));
    }
}

84. Deterministyczność

System deterministyczny - dla tych samych danych wejściowych zawsze daje ten sam wynik. Brak losowości i efektów ubocznych.

// DETERMINISTYCZNA - zawsze ten sam wynik dla tych samych argumentów
public int add(int a, int b) {
    return a + b;
}

// NIEDETERMINISTYCZNA - wynik zależy od czasu
public String generateId() {
    return UUID.randomUUID().toString();  // losowy wynik
}

// Jak uczynić kod deterministycznym w testach:
public class OrderService {
    private final Clock clock;  // wstrzykujemy zegar

    public Order createOrder() {
        return new Order(LocalDateTime.now(clock));  // deterministyczne w testach
    }
}

85. Deserializacja

Deserializacja - proces zamiany danych z formatu tekstowego/binarnego (JSON, XML) na obiekty w pamięci.

// Jackson - deserializacja JSON → Object
ObjectMapper mapper = new ObjectMapper();

// Deserializacja
String json = "{\"name\": \"Jan\", \"age\": 30}";
User user = mapper.readValue(json, User.class);

// Serializacja
String jsonOutput = mapper.writeValueAsString(user);

// Spring automatycznie deserializuje body requestu
@PostMapping("/users")
public User createUser(@RequestBody User user) {  // JSON → User
    return userService.save(user);
}

Ryzyka bezpieczeństwa:

• Deserializacja niezaufanych danych może prowadzić do RCE (Remote Code Execution)
• Zawsze waliduj dane wejściowe
• Używaj @JsonIgnoreProperties(ignoreUnknown = true)

86. @RequestParam vs @PathVariable vs @QueryParam

Adnotacje służące do pobierania parametrów z żądania HTTP.

// Spring - @PathVariable i @RequestParam
@GetMapping("/users/{id}")
public User getUser(
    @PathVariable Long id,                         // /users/123
    @RequestParam(required = false) String fields  // ?fields=name,email
) { ... }

// Paginacja i sortowanie
@GetMapping("/products")
public List<Product> getProducts(
    @RequestParam(defaultValue = "0") int page,
    @RequestParam(defaultValue = "10") int size,
    @RequestParam(defaultValue = "name") String sortBy
) { ... }

// JAX-RS - @QueryParam
@GET
@Path("/users")
public List<User> getUsers(@QueryParam("age") int age) { ... }

87. Tokenowanie

Tokenowanie - zamiana danych wrażliwych na token (losowy identyfikator). Token sam w sobie nie zawiera danych.

// Tokenowanie numeru karty płatniczej
@Service
public class TokenizationService {

    private final TokenRepository tokenRepository;

    public String tokenize(String cardNumber) {
        String token = UUID.randomUUID().toString();
        tokenRepository.save(new TokenMapping(token, encrypt(cardNumber)));
        return token;  // "tok_abc123" zamiast "4111111111111111"
    }

    public String detokenize(String token) {
        return tokenRepository.findByToken(token)
            .map(m -> decrypt(m.getEncryptedData()))
            .orElseThrow();
    }
}

Zastosowania: płatności (PCI DSS), dane osobowe (RODO), sesje użytkowników

88. DNS (Domain Name System)

DNS - system tłumaczący nazwy domenowe na adresy IP.

Znaczenie w architekturze:

• Load balancing - jeden DNS, wiele IP (Round Robin)
• Service discovery - Kubernetes DNS (service.namespace.svc.cluster.local)
• Failover - przekierowanie ruchu przy awarii

89. Prefix URL i wersjonowanie API

Prefix - wspólny początek ścieżki URL dla grupy endpointów.

// Prefix na poziomie kontrolera
@RestController
@RequestMapping("/api/v1/users")  // prefix: /api/v1/users
public class UserController {

    @GetMapping          // GET /api/v1/users
    public List<User> getAll() { ... }

    @GetMapping("/{id}") // GET /api/v1/users/123
    public User getById(@PathVariable Long id) { ... }
}

// Globalny prefix w application.yml
server:
  servlet:
    context-path: /api