Aliaksei Taliuk’s Post

📣 Appify Prefab 0.5.0 is now live on Maven Central. This release is all about making your domain models more expressive while keeping the infrastructure invisible. Here is what is new: - Richer Types: Support for single-field value types. You can now use dedicated types like Email or PhoneNumber instead of generic Strings for your domain logic. - Automatic Docs: Async API documentation is now generated directly from your events. Your documentation stays in sync with your code automatically. - Persistence: MongoDB support is officially here. Whether you need relational or document-based storage, Prefab handles the boilerplate. - Schema-First: Generate your domain events directly from AVSC files if you prefer starting with the schema. Important Change: - Safety First: Fields are now @NotNull by default. To make a field optional, you must now explicitly use the @Nullable annotation. We are pushing for "Safe by Default" to catch potential issues before they ever hit a runtime environment. Read the full changelog here: https://lnkd.in/eweK7MCg #Java #SpringBoot #MongoDB #EDA #SoftwareArchitecture #DDD

5 Spring Boot annotations I use every single day in production: 𝟭. @RestController Combines @Controller + @ResponseBody. Every API endpoint class starts here. 𝟮. @Service Marks your business logic layer. Controllers stay thin, services stay fat. 𝟯. @Transactional Wraps a method in a database transaction. If anything fails — everything rolls back. Non-negotiable for payment flows. 𝟰. @Cacheable Caches method results (we use it with Redis). First call = DB hit. Every call after = instant cache response. 𝟱. @KafkaListener Listens to a Kafka topic and processes events. This is how our microservices communicate without tight coupling. Example: @KafkaListener(topics = "ticket-created", groupId = "crm-group") public void handleTicket(TicketEvent event) {   notificationService.sendAlert(event); } These 5 annotations alone cover 80% of what I write daily. Which annotation do you find most useful? Drop it below 👇 #SpringBoot #Java #BackendDevelopment #Microservices #JavaDeveloper

One of the most common distributed-systems bugs I've seen across different teams is the duplicate-charge or duplicate-action problem. It usually comes down to a missing idempotency key. The pattern: a client retries a request after a timeout. The original request had actually succeeded - the response just never made it back. Result: two charges, one unhappy user, one urgent on-call ticket. Idempotency in REST APIs is one of those topics that sounds straightforward until it surfaces in production. The mental model I use: GET, PUT, DELETE → idempotent by HTTP spec. Same request, same result, no side effects on retry. POST → not idempotent by default. This is where most idempotency bugs come from. The fix isn't complicated. For any POST that creates or modifies state, accept an Idempotency-Key header from the client. Store the key and the response in a short-lived cache (Redis works well, with a TTL of a few hours to a day). On a retry with the same key, return the cached response instead of re-processing. Three things that often get missed: 1. The key has to be generated by the client, not the server. Server-generated keys defeat the purpose. 2. Cache the response, not just a "this key was used" flag. Otherwise the retry gets a different shape than the original. 3. Scope keys per endpoint or per user. Global key spaces lead to weird collisions. Idempotency is one of the lowest-cost, highest-value patterns you can build into a distributed system. Easy to skip during initial design. Painful to retrofit after an incident. What's your team's pattern for this - header-based, request-hash-based, or something else? #Java #SpringBoot #Microservices #DistributedSystems #BackendEngineering #SoftwareEngineering #APIDesign #TechLeadership

-:Improving API Performance in Spring Boot :- Optimizing APIs in Spring Boot is crucial for building scalable and high-performance backend systems. Here are some practical techniques that made a real difference in my projects: ✔ Use Caching (@Cacheable) Reduce repeated DB calls using Spring Cache with Redis/EhCache. ➡️ @Cacheable, @CacheEvict can significantly cut response time. ✔ Optimize Database Access (JPA/Hibernate) • Use proper indexes • Avoid N+1 queries • Use DTO projections instead of fetching full entities ✔ Connection Pooling (HikariCP) • Spring Boot uses HikariCP by default — tune pool size for better throughput. ✔ Pagination Instead of Large Responses Use Pageable to limit data returned per request. ✔ Lazy Loading & Fetch Strategies Avoid unnecessary data fetching using FetchType.LAZY. ✔ Actuator + Monitoring Track performance using Spring Boot Actuator ✔ API Rate Limiting Use tools like Bucket4j to prevent overload. What’s your technique for improving Spring Boot performance? comment here 👇 #SpringBoot #Java #Backend #API #Performance #Microservices #Hibernate #Coding #Tech

🚀 Real-Time Notification Engine: Event-Driven with Kafka & WebSockets Real-time visibility is no longer a "nice-to-have"—it’s a modern requirement for distributed systems. 🏗️ I just finished building an event-driven notification engine for my Inventory Management System using the absolute latest Java/Spring ecosystem. The magic happens when an order status hits "DELIVERED": The Trigger: The Order Service persists the change and a Kafka Producer fires an asynchronous event. No waiting, no blocking. The Processing: A dedicated Notification Service consumes the message. Because it's asynchronous, the main order flow stays blazing fast and responsive. ⚡ The Delivery: Using STOMP over WebSockets, the update is pushed live to the user's dashboard instantly. No "refresh" button needed. 🔔 The Architectural Win: By using an event-driven approach, the Order Service is completely decoupled from the notification logic (SMS, Emails, etc.). We maintain a "lean" core while allowing the notification system to scale horizontally without breaking a sweat. Tech Stack (Bleeding Edge): Language: Java 25 ☕ Framework: Spring Boot 4.x Messaging: Apache Kafka (Event-Driven) Real-time: Spring WebSocket + STOMP Data Integrity: Optimistic Locking (Preventing overselling) Caching: Redis How are you handling real-time updates in your systems? Are you sticking with WebSockets, or exploring Server-Sent Events (SSE)? Let's discuss in the comments! 👇 #Java25 #SpringBoot #Kafka #WebSockets #BackendEngineering #SystemDesign #EventDriven #Architecture

🚀 Just shipped the Event-Booking-Microservices-Platform — a production-grade Microservices system! Built with Java & Spring Boot , here’s what’s inside: 🧩 8 microservices — User, Event, Booking, Payment, Notification + Gateway, Eureka, Config Server 🔐 JWT + OAuth2 (Google Login) with RBAC at the gateway level ⚡ Kafka-driven async flows — BookingCreated → Payment → Notification 🔗 OpenFeign + Resilience4j circuit breakers for fault tolerance 🐘 Database per service (PostgreSQL) — true isolation 🐳 Fully containerized with Docker Compose The biggest lesson? Design for failure, not just for success. Next: Redis caching · Kubernetes · CI/CD 🔧 🔗 GitHub: https://lnkd.in/dch3hrcG 🌐 Portfolio: https://lnkd.in/dndjUxwU Open to feedback from anyone in the microservices space 🤝 #SpringBoot #Microservices #Java #Kafka #SystemDesign #BackendDevelopment #Docker #CloudNative

🚨 Why your 4GB JVM app still gets OOMKilled (even when heap looks fine) Most developers assume: JVM memory = Heap But that’s only part of the story. Let’s look at a common real-world setup: You configure: -Xmx=4g Container memory limit = 4GB Looks perfect, right? ❌ Not really. Your JVM uses much more than just heap. Here’s where the “hidden” memory goes: 🔹 Metaspace Stores class metadata (Spring, Hibernate, proxies) ~150–250MB (no strict cap by default) 🔹 Thread Stacks Each thread ≈ 1MB 200 threads = ~200MB (Tomcat + HikariCP + Kafka + @Async) 🔹 Direct Buffers (Off-Heap) Used by WebClient, Kafka, Netty - Not visible in heap, not GC-managed 🔹 Code Cache JIT compiled code ~50–150MB (grows as app warms up) 🔹 GC Overhead Garbage collector needs working memory too 💥 Reality Check 4GB heap + 200MB metaspace + 200MB threads + 100MB buffers + 100MB code cache 👉 Total ≈ 4.7GB But your container limit is still 4GB. Result? 🚫 Kubernetes OOMKills your pod And the confusing part: ✔️ Heap looks fine (~2.5GB used) ❌ But your app still crashes Because OOMKill is based on total process memory, not just heap. ✅ The Fix ✔️ Keep heap at 70–75% of container memory ✔️ If container = 4GB → set -Xmx=3g ✔️ If -Xmx=4g → container ≥ 5.2GB ✔️ Cap metaspace: -XX:MaxMetaspaceSize=256m ✔️ Cap direct memory: -XX:MaxDirectMemorySize=256m ✔️ Monitor non-heap usage: /actuator/metrics/jvm.memory.used 💡 Takeaway If you're only monitoring heap, you're missing the full picture. 👉 Always consider total JVM memory footprint in containerized environments. #Java #JVM #SpringBoot #Kubernetes #Microservices #DevOps #Performance #BackendEngineering #SoftwareEngineering #Programming

5 Node.js mistakes that slow your API (I made all of these in my first 2 years) Most developers blame their server when their API is slow. It's rarely the server. Here are 5 mistakes I see killing Node.js API performance: 1. Blocking the event loop Running heavy sync operations in the main thread freezes everything. Move CPU-heavy tasks to worker threads or a background queue. 2. No database query limits Fetching all records "just in case" will destroy your response time. Always paginate. Always limit. Always project only the fields you need. 3. Skipping compression Not using gzip or Brotli on your responses is free performance left on the table. One middleware line. Huge difference. 4. Creating new DB connections on every request If you're not using a connection pool, you're rebuilding the tunnel every time. Use Mongoose's built-in pooling or pg-pool for PostgreSQL. 5. No caching layer Hitting your database for the same data 1000 times a day. Redis can serve repeat queries in under 1ms. Slow APIs lose users before they even see your product. Which of these have you run into? #nodejs #mernstack #javascript #webdevelopment #backenddevelopment

🚀 I built a .NET API template that developers can actually use in real projects. Most examples online are either: ❌ Too basic (just CRUD) ❌ Too complex (over-engineered “enterprise” demos) So I created something practical 👇 💡 Clean Architecture .NET 8 API Template ✔ Production-ready ✔ Easy to understand ✔ Easy to extend 🔥 What’s inside? ✅ Clean Architecture ✅ CQRS with MediatR ✅ Redis caching (via pipeline 🔥) ✅ FluentValidation ✅ JWT Authentication ✅ Global Exception Handling ✅ Serilog Logging ✅ Swagger ✅ Docker support 🧠 Why this matters? In real-world systems, you don’t need: ❌ 10 design patterns for CRUD ❌ Over-complicated setup You need: 👉 Clean structure 👉 Maintainable code 👉 Scalable foundation That’s exactly what this repo provides. ⚡ Highlight Caching is implemented using MediatR Pipeline Behavior 👉 No cache logic inside handlers 👉 Clean and reusable 👉 Real-world pattern 📦 Repo https://lnkd.in/gVw2-apa If you're working with .NET APIs, this might save you hours of setup. Would love your feedback 🙌 #dotnet #webapi #cleanarchitecture #cqrs #redis #backenddevelopment #softwareengineering

We wrote 60,000 lines of Rust to power a TypeScript framework, and are now sharing what that journey actually looked like. The runtime handles everything underneath your application code - HTTP, databases, pub/sub, tracing, caching, API gateway - all running multi-threaded in the same process as Node.js. Give it a read: https://lnkd.in/dd-bwM-J